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From  the  Sponsor 

Software:  Where  WeVe  Been 
And  Where  WeVe  Going 


Has  software  design  finally  come  of  age?  Mechanical,  electrical,  chemical,  industrial, 
and  other  engineering  design  disciplines  have  been  in  place  for  centuries  and  have 
experienced  the  associated  growth  and  cross-pollination  of  shared  concepts,  tools,  trial 
and  error,  etc.  However,  software  engineering  is  still  relatively  new. 

The  discipline  of  software  design  has  only  been  matured  for  a  few  decades.  It  wasn’t 
until  the  1960s  that  the  first  software  products  hit  the  marketplace.  Standards  such  as 
American  Standard  Code  for  Information  Interchange  and  concepts  such  as  object-ori¬ 
ented  code  didn’t  appear  until  the  1960s.  Our  dominant  programming  language  C++  didn’t  emerge 
until  the  1980s.  More  recently,  we  have  seen  design  tools  such  as  CASE  [Computer-Aided  Software 
Engineering]  and  fourth  generation  programming  languages. 

Our  discipline  of  software  engineering  has  really  experienced  phenomenal  growth  right  before 
our  eyes.  A  sign  that  software  design  has  really  arrived  is  indicated  by  the  hardware  changes  that 
are  being  driven  by  the  complexity  of  software  designs.  Our  phenomenal  growth  is  also  accompa¬ 
nied  by  real  challenges.  The  increasing  complexity  of  our  software  also  necessitates  that  our  indus¬ 
try  stay  focused  on  process  improvement.  As  you  read  some  of  this  month’s  articles,  take  yourself 
back  10  or  20  years,  and  revel  at  how  far  we  have  come,  but  also  envision  where  we  need  to  go. 


Kevin  Stamey 

Oklahoma  City  A.ir  Logistics  Center,  Co-Sponsor 


From  the  Publisher 


Design  Focuses  on  the  How 


This  month  we  cover  another  critical  phase  in  the  software  system  life  cycle  -  design. 

Industry  has  been  successful  over  time  with  emphasizing  and  providing  many 
methods  and  tools  for  improving  design.  Software  engineers  know  their  hands  will  be 
slapped  if  they  rush  from  requirements  to  programming  code  without  taking  the  time 
to  design.  The  design  phase  can  be  looked  at  as  a  problem-solving  process.  Another 
way  to  think  of  design  is  to  focus  on  the  ho^r.  Requirements  are  focused  on  n^hat  prob¬ 
lem  will  be  solved.  The  design  focuses  on  ho^r  the  problem  will  be  solved. 

Our  theme  section  begins  with  S  electing  A.rchitecture  Products  for  a  Systems  development  Program  by 
Michael  S.  Russell.  This  author  describes  a  repeatable  process  that  emphasizes  architecture  as 
the  source  of  information  that  decision  makers  can  turn  to  throughout  the  systems  engineering 
process.  In  Dependency  Models  to  Manage  Software  Architecture^  Neeraj  Sangal  and  Erank  Waldman 
relate  a  new  approach  using  inter-module  dependencies  to  specify  and  manage  system  architec¬ 
ture.  Next,  in  UML  Design  and  Auto-Generated  Code:  Issues  and  Practical  Solutions  by  Ilya  Lipkin  and 
Dr.  A.  Kris  Huber,  lessons  learned  from  designing  with  the  Unified  Modeling  Language  (UML) 
are  presented  from  a  real-time  control  system  perspective.  Lastly,  Dr.  Hans-Peter  Hoffmann 
describes  how  systems  engineers  can  capture  requirements  and  specify  architecture  in  UML  2.0- 
Based  Systems  Engineering  Using  a  Model-Driven  Development  Approach. 

In  this  month’s  supporting  articles,  Arlene  E  Minkiewicz  and  Jeffrey  Voas  each  offer  addi¬ 
tional  information  on  software  security,  another  important  factor  to  consider  during  the  design 
phase.  I  hope  this  month’s  issue  provides  helpful  information  as  new  and  improved  methods 
continue  to  evolve  design  processes. 

Tracy  L.  Stauder 
Publisher 
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Selecting  Architecture  Products  for  a 
Systems  Development  Program 

Michael  S.  Russell 
A^nteon  Corporation 

JPetermining  what  architecture  products  are  needed  to  support  software  development  within  a  larger  systems  engineering  process 
is  a  challenge.  Existing  documents  such  as  the  Department  of  Defense  Architecture  Eramework  provide  some  guidance,  but 
no  defined  product  identification  process.  The  method  proposed  in  this  article  provides  a  repeatable  process  for  selecting  the 
architecture  products  required  to  support  a  larger  systems  engineering  effort,  defines  the  content  of  each  product,  and  identi¬ 
fies  each  producfs  customer. 


The  purpose  of  architecture  is  to 
answer  questions.  In  other  words,  the 
architecture  provides  the  information 
needed  by  decision  makers  during  the 
course  of  the  systems  engineering 
process  to  define  concepts  and  processes, 
allocate  functionality,  define  test  metrics, 
design  software,  and  make  other  develop¬ 
ment  decisions.  However,  the  output  of 
the  systems  engineering  (SE)  process  is 
not  the  architecture;  rather,  it  is  the  sys¬ 
tem  being  produced  [1].  Unfortunately, 
the  architecture  often  becomes  divested 
from  the  SE  process  it  is  meant  to  sup¬ 
port,  becoming  an  output  or  deliverable 
in  and  of  itself  [2]. 

In  part,  this  is  perpetuated  by  govern¬ 
ment  regulations  specifying  that  each 
acquisition  program  produce  architecture 
with  little  thought  as  to  how  architecture 
will  be  used  by  the  program  [3,  4,  5].  So, 
the  output  of  most  architecture  efforts 
tends  to  be  a  three-ring  binder  that 
weighs  five  pounds  or  so,  which  no  one 
ever  reads.  This  has  given  a  bad  name  to 
the  architecting  process,  and  has  left 
many  decision  makers  asking  why  they 
spent  their  limited  money  and  time  pro¬ 
ducing  architectures. 

To  correct  this  situation,  both  the 
software-centric  and  system-centric  com¬ 
munities  need  to  reexamine  the  architect¬ 
ing  process,  rediscover  the  intended  uses 
for  architecture,  and  ensure  architecting 
is  always  done  in  support  of  the  SE  life 
cycle.  For  software  designers,  this  will 
mean  a  break  from  the  concept  that  four 
or  five  standard  Unified  Modeling 
Language  (UML)  diagrams  wiU  solve  the 
needs  of  all  stakeholders.  This  article 
presents  one  method  for  ensuring  the 
architecture  is  producing  the  products 
needed  to  support  the  overall  SE  process. 

Tying  Architectures  Into  the 
SE  Process 

The  SE  process  has  been  described  as 
an  elaborate  engineering  decision 


process  that  includes  the  following  [6]: 

•  Begins  with  understanding  the  sys¬ 
tem  requirements  and  specifications. 

•  Translates  these  specifications  into  a 
conceptual  design  in  the  form  of  a 
functional  architecture. 

•  Translates  this  functional  architec¬ 
ture  into  logical  design  or  physical 
architecture. 

^^Developing  architecture 
as  part  of  a  program's 
SE  [systems  engineering] 
process  can  be  a 
critical  component  of  the 
program's  success,  but 
only  if  the  right  products 
are  identified  and 
produced  at  the  right 
time  for  the 
right  customer. 


•  Translates  the  physical  architecture 
into  a  detailed  design  or  implemen¬ 
tation  architecture  for  the  system 
ultimately  to  be  produced  or 
acquired. 

•  Completes  development  through  the 
production  of  a  product  that  con¬ 
forms  to  this  architecture,  potential¬ 
ly  through  various  strategic  sourcing 
efforts  and  associated  integration 
and  test. 

These  steps  show  the  SE  process  for 
what  it  really  is  —  a  series  of  decision 
points  leading  up  to  a  delivered  product. 
This  means  the  architecture’s  products 
must  be  tied  to  the  rest  of  the  SE 


process  and,  more  specifically,  to  deci¬ 
sion  points  within  that  process.  This 
allows  the  architect  to  determine  what 
products  need  to  be  produced,  when  to 
produce  them,  and  what  level  of  detail 
needs  to  be  present.  To  tie  architecture 
products  to  decision  points,  the  archi¬ 
tect  must  understand  what  decisions 
need  to  be  made.  It  is  a  process  that 
begins  with  these  questions: 

1.  What  is  the  output  of  my  SE 
process? 

2.  What  decisions  need  to  be  made  to 
produce  the  output? 

3.  What  sort  of  information  is  needed 
to  make  those  decisions? 

4.  Which  architecture  products  provide 
the  information  in  a  format  that  is 
understandable  to  the  decision 
maker? 

5.  When  are  the  architecture  products 
needed? 

6.  How  should  my  project  be  staffed  to 
produce  those  products? 

7.  Which  software  tools  will  help  the 
architect  build  those  products? 

For  example,  if  the  output  of  the  SE 
process  is  an  electronic  timecard  sys¬ 
tem,  then  decisions  include  these: 
‘'What  are  the  expectations  of  its 
users?”  “How  many  employees  will  use 
it  concurrently?”  “What  technology 
options  exist?”  and  “Which  technical 
option  works  best  with  the  existing 
timekeeping  business  process?” 
Concerning  the  time  card  software 
itself,  the  decision  maker  would  proba¬ 
bly  like  to  know  the  advantages  and  dis¬ 
advantages  of  different  ways  of  enter¬ 
ing  time  card  data,  ease  of  updating  and 
maintenance,  and  how  the  software  will 
interoperate  with  the  business’  existing 
software. 

Each  of  these  decisions  is  made  at  a 
different  point  in  the  SE  process,  and 
many  of  the  decisions  are  interdepend¬ 
ent.  It  is  the  architect’s  job  to  recognize 
this  and  suggest  the  appropriate  mix  of 
architecture  products  that  will  provide 
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START 


Figure  1 :  Product  Identification  Process 


the  needed  information  —  in  essence, 
answer  the  questions.  Figure  1  describes 
this  process. 

Please  note  that  the  last  step  in  the 
process  concerns  what  software  tools  are 
needed  to  build  the  architecture  products. 
Too  often,  a  project  starts  with  the 
notion,  “We’re  using  XX  company’s 
tool,”  without  considering  how  that  soft¬ 
ware  will  be  used  or  even  if  it  can  be  used 
within  the  program’s  existing  SE  process. 
In  fact,  many  of  these  tools  assume  an 
SE  process,  and  the  software  is  optimized 
to  produce  architecture  products 
designed  for  that  process  (i.e.,  the 
Rational  Unified  Process)  [7].  While  this 
is  not  necessarily  a  bad  thing,  it  does 
mean  that  the  chosen  tool  is  driving 
product  selection  and  the  overall  process 
to  produce  the  architecture  products. 
Sometimes  this  situation  is  directed  such 
as  a  program  that  is  required  to  use  a 
model-driven  architecture  [8]  approach. 
Ideally,  the  software  tool  should  be  cho¬ 
sen  after  the  products  to  be  built  have 
been  identified. 

Remember  that  decisions  made  early 
in  the  SE  process  require  different  infor¬ 
mation  than  those  decisions  made  closer 
to  the  end.  For  instance,  describing  the 
business  process  that  a  new  system  wiU 
support  is  done  early  on,  while  defining 
software  to  support  that  process  is  done 
later.  Understanding  when  information  is 
useful  to  a  decision  maker  is  just  as 
important  as  understanding  what  infor¬ 
mation  he  or  she  needs. 

Finally,  a  system  has  many  customers. 
The  electronic  timecard  system  described 
in  the  earlier  example  has  an  obvious  cus¬ 
tomer:  the  employee.  However,  there  are 
many  other  customers  such  as  the  system 
developers,  the  company’s  executives, 
time  card  system  vendors,  and  the  com¬ 
pany’s  accounting  department.  Each  of 
these  customers  has  an  interest  in  the  new 
system,  but  each  makes  different  deci¬ 
sions  and  needs  different  information  to 
make  those  decisions.  A  well-built  archi¬ 
tecture  takes  all  of  these  needs  into  con¬ 
sideration  and  is  capable  of  producing  the 
right  architecture  product,  in  the  optimal 
format,  to  meet  each  customer’s  need. 

The  Product  Identification 
Process 

The  product  identification  process  out¬ 
lined  in  this  article  is  a  matrix-based 
approach  used  successfully  by  several 
DoD  organizations  over  the  past  five 
years,  and  is  also  taught  in  the  Federal 
Enterprise  Architecture  Certification 
(FEAC)  Institute’s  [9]  certification  pro¬ 


gram.  The  matrices  can  be  produced 
with  most  any  office  automation  or 
database  software.  However,  the  matrix 
is  normally  put  together  in  a  spread¬ 
sheet.  To  help  examine  how  the  process 
would  be  implemented,  a  completed  set 
of  matrices  using  the  electronic  time¬ 
card  example  are  included  in  the  online 
version  of  this  article  at  < www.stsc.hill. 
af.mil/  crosstalk/  2005  /  1  1  /  051  1 
Russell.html>.  The  matrices  presented 
below  contain  a  subset  of  the  same 
information. 

Step  One 

Step  one  focuses  on  identifying  the 
architecture’s  customers  and  determin¬ 
ing  each  customer’s  questions  or  deci¬ 
sions  they  need  to  make.  In  the 
Customer-Question  Matrix  (Figure  2), 
the  customers  are  listed  along  the  top 
axis  and  a  list  of  questions  along  the  left 
axis.  Next,  the  information  needed  to 


answer  each  customer’s  question  is 
added  to  the  matrix.  Developing  this 
matrix  can  be  greatly  improved  by  let¬ 
ting  each  customer  see  the  responses  of 
other  customers.  This  typically  results  in 
less  question  redundancy,  especially 
when  the  information  needs  between 
customers  are  similar. 

Step  Two 

In  step  two,  the  focus  shifts  from  the 
customer’s  questions  and  decision 
points  to  which  architecture  products 
provide  the  information  needed  to 
answer  the  questions  or  support  a  deci¬ 
sion.  It  is  important  to  remember  that 
even  when  several  customers  need  simi¬ 
lar  information,  the  architecture  prod¬ 
uct  and  the  level  of  detail  for  that  prod¬ 
uct  might  be  different.  For  example,  a 
business  executive  and  a  programmer 
would  both  need  to  understand  the  con¬ 
cept  for  the  company’s  new  timecard 


Figure  2:  Customer-Question  Matrix 


Customers: 

Questions: 

Business  Owner/ 
Managers 

Finance 

Department 

Information 
Technology  (IT) 
Department 

Users 

How  will 
it  be 

deployed? 

Deployment 
milestones, 
overarching  plan,  IT 
integration  plan. 

Deployment 
milestones, 
overarching  plan. 

Deployment 
milestones, 
overarching  plan, 
interaction  with 
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system,  but  the  level  of  detail  needed  by 
each  would  be  much  different. 

For  this  Product-Information  Matrix 
(Figure  3),  the  information  needed  by 
each  customer  is  listed  on  the  left  axis, 
and  architecture  products  that  could 
provide  that  information  are  listed 
along  the  top  axis.  Quite  often,  the 
information  needed  will  span  several 
architecture  products.  For  instance, 
determining  who  can  update  a  compa¬ 
ny’s  human  resources  database  and 
under  what  conditions  an  update  can 
occur  may  require  activity  diagrams,  a 
logical  data  model,  a  business  rules 
model,  and  other  architecture  products. 

When  possible,  information  needs  as 
described  by  the  customers  should  be 
consolidated  so  the  matrix  does  not 
become  unwieldy,  but  only  when  the 
information  needed  is  at  the  same  level 
of  detail.  Although  two  customers  may 
need  the  same  type  of  information  to 
answer  their  question,  the  information 
they  need  may  reflect  a  different  level  of 
detail.  For  example,  if  a  business  owner 
wants  to  understand  database  access 


permissions,  then  a  business  rules 
model  might  be  the  best  architecture 
product  to  provide  the  information. 
However,  the  database  developer  would 
need  a  data  model  based  on  the  business 
rules  to  build  the  database.  Few  busi¬ 
ness  owners  will  look  at  or  understand  a 
data  model,  but  it  is  the  right  product 
for  the  developer. 

Step  Three 

The  next  step  in  the  process  matches 
each  customer  with  the  set  of  architec¬ 
ture  products  they  need  to  answer  ques¬ 
tions  and  make  decisions  in  a  timely 
manner.  This  step  gives  the  architecture 
developers  the  information  they  need  to 
plan  the  architecture  development 
process  and  integrate  it  into  the  overall 
SE  process.  The  Customer-Product 
Matrix  (Figure  4)  supports  this  map¬ 
ping,  identifies  when  each  product  is 
needed,  and  highlights  dependencies 
between  products.  In  this  matrix,  the 
customers  are  again  listed  along  the  top 
axis,  while  the  architecture  products  are 
listed  on  the  left  axis.  Delivery  dates. 


product  formats,  i.e.,  activity  diagram 
versus  data  flow  diagram,  metrics,  and 
other  information  should  be  used  to 
indicate  the  mapping  between  cus¬ 
tomers  and  products. 

It  is  likely  that  a  specific  product 
such  as  the  activity  model  will  be  identified 
as  being  used  by  multiple  customers. 
Keep  in  mind  that  each  customer  will 
probably  use  his  or  her  activity  model  in 
a  different  manner,  which  should  be 
captured  in  the  information  section  of  the 
first  matrix.  This  means  that  there  prob¬ 
ably  will  not  be  one  activity  model  for 
the  architecture.  Rather,  there  will  be 
several  views  of  the  activity  model  that 
are  relevant  to  a  specific  customer’s 
information  needs,  derived  from  the 
same  pool  of  architectural  data. 

Step  Four 

Now  that  architecture  products  needed 
to  support  the  SE  process  have  been 
identified,  the  last  step  is  to  choose  the 
software  tools  that  the  architects  will  use 
to  produce  products  in  a  format  useful 
for  each  customer’s  decision-making 
process.  Typically,  an  executive-level  deci¬ 
sion  maker  will  not  want  to  look  at  a 
product  as  displayed  in  a  Computer 
Aided  Systems  Engineering  (CASE)  tool, 
while  a  software  developer  will  not  get 
the  information  they  need  from  a  Power 
Point  presentation.  So  the  architecture 
should  rely  on  a  suite  of  tools  to  pro¬ 
duce,  store,  and  display  the  architecture’s 
products.  Each  tool  serves  a  defined  pur¬ 
pose  within  the  architecture,  and  togeth¬ 
er  they  support  the  creation  and  integra¬ 
tion  of  the  architecture. 

Generally,  there  are  four  types  of 
software  tools  used  to  support  architec¬ 
ture  development:  CASE  tools,  databas¬ 
es,  executable  modeling  tools,  and  Web 
sites.  Normally,  one  tool  of  each  type  is 
needed  because  each  customer  has  dif¬ 
ferent  needs  for  viewing  and  using  his 
or  her  architecture  products.  One  word 
of  caution,  even  though  many  vendors 
will  try  to  sell  a  one-sic^e-fits-all  software 
solution,  very  few  tools  support  all 
aspects  of  your  development  process. 
So  choose  the  tool  that  provides  the 
information  needed  by  that  customer  to 
support  his  or  her  decision-making 
process.  Do  not  expect  a  customer  to 
modify  his  or  her  SE  process  or  deci¬ 
sion-making  criteria  just  because  your 
software  cannot  deliver  the  architecture 
in  a  form  he  or  she  can  use. 

Other  Uses  for  the  Matrices 

Understanding  what  products  to  produce 
is  only  half  the  challenge.  The  next  chal- 


Figure  4:  Customer-Product  Matrix 


Architecture 

Products: 

Customer: 

Business  Owner/ 
Managers 

Finance 

Department 

IT  Department 

Users 

System  Concept 

DEC 

DEC 

DEC 

Activity 
and  Process 
Diagrams 

JAN  -  High  Level 
APR -Final 

JAN  -  High  Level 
MAR  -  Detailed 

JAN  -  High  Level 
MAR  -  Detailed 

MAR  -  Detailed 

Business  Ruies 
Description 

JAN  -  Initial 

MAR  -  Detailed 

JAN  -  Initial 

MAR  -  Detailed 

APR -Final 

Reguiation 

Compiiance 

Traceabiiity 

Matrix 

APR 

Data  Modei 

MAR  -  Business 

Rule  Text 

FEB  -  UML  Class 
Diagram 

6  CrossTalk  The  Journal  of  Defense  Software  Engineering 


November  2005 


Selecting  Architecture  Products  for  a  Systems  Development  Program 


lenge  is  determining  how  to  staff  the 
development  project,  including  how 
many  people  to  hire  and  what  skills  those 
people  should  have.  The  information 
contained  in  the  matrices  can  also  help 
answer  these  questions.  For  example, 
data  models  are  generally  produced  later 
in  the  SE  life  cycle  than  system  use  cases 
are  produced,  meaning  a  project  may  not 
need  to  hire  a  data  modeler  at  the  very 
beginning  of  the  project.  Likewise,  a 
completed  set  of  matrices  will  normally 
show  a  need  for  several  systems  analysts 
toward  the  beginning  of  the  life  cycle, 
one  or  two  during  the  middle,  and  a  large 
group  at  the  end  during  the  test  and  eval¬ 
uation  stage. 

So,  by  matching  the  expected  deliv¬ 
ery  dates  for  each  architecture  product 
captured  in  the  matrix,  a  good  initial 
staff  skill  set  and  loading  matrix  can  be 
produced.  Staffing  choices  are  not 
always  intuitive,  and  the  completed 
matrices  can  significantly  help  the  pro¬ 
gram  manager  justify  his  project  fund¬ 
ing  requirements  by  having  hard  num¬ 
bers  to  base  his  staffing  plan  upon. 

Conclusion 

The  purpose  of  architecture  is  to  provide 
the  information  needed  by  decision  mak¬ 
ers  to  make  decisions.  Developing  an 
architecture  as  part  of  a  program’s  SE 
process  can  be  a  critical  component  of  the 
program’s  success,  but  only  if  the  right 
products  are  identified  and  produced  at 
the  right  time  for  the  right  customer. 

The  matrix-based  approach  outlined 
here  has  proven  to  be  a  repeatable  and 
successful  process  for  its  users.  When 
used  early  in  the  SE  life  cycle,  it  helps 
focus  developers  on  how  the  architec¬ 
ture  should  be  used  by  zeroing  in  on  the 
questions  to  be  answered  and  the  infor¬ 
mation  needed  to  answer  those  ques¬ 
tions.  During  production,  it  helps  set 
customer  expectations  concerning  the 
types  of  products  to  be  produced,  the 
level  of  effort  and  skills  required  to  pro¬ 
duce  the  products,  and  when  each  prod¬ 
uct  will  be  delivered.  At  any  time  during 
the  life  cycle,  the  information  can  be 
used  to  show  what  decisions  need  to  be 
made  and  what  architectural  informa¬ 
tion  these  decisions  should  be  based  on. 

Lastly,  the  matrices  form  a  body  of 
knowledge  that  can  be  reused  when 
planning  future  projects.^ 
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This  article  describes  a  new  approach  for  managing  software  architectures.  It  uses  inter-module  dependencies  to  specify  and 
manage  the  architecture  of  software  applications.  The  technique,  based  on  a  matrix  representation,  is  simple,  intuitive,  and 
appears  to  scale  far  better  than  the  directed  graph  representations  that  are  used  currently.  It  enables  specification  and  auto¬ 
matic  enforcement  of  architectural  intent  such  as  layering  and  componenti^tion.  The  article  concludes  by  showing  how  this 
approach  can  be  applied  to  a  real  application.  We  build  a  dependency  model  to  represent  the  architecture  of  A.nt,  a  popular 
Java  build  utility.  We  then  examine  how  Anfs  architecture  has  evolved  over  several  versions  of  the  software. 


Software  development  has  a  way  of 
becoming  difficult  over  time.  While 
they  often  start  well,  software  projects 
begin  to  bog  down  as  enhancements  are 
made  to  meet  new  demands  and  as  devel¬ 
opment  teams  change.  It  takes  longer  to 
fix  problems  because  fixes  made  in  one 
area  end  up  introducing  bugs  in  other 
areas.  In  no  time,  a  project  becomes  so 
complex  that  no  single  engineer  under¬ 
stands  the  whole  system.  As  a  result,  orig¬ 
inal  design  assumptions  are  lost  and  the 
boundary  between  various  parts  of  the 
system  begins  to  blur.  Systems  that  started 
out  as  modular  become  monolithic. 

A  powerful  new  approach,  based  on 
using  the  Dependency  Structure  Matrix 
(DSM),  has  recently  been  proposed  for 
specifying  software  architectures.  This 
approach  has  been  built  upon  ideas  that 
have  actually  been  around  for  a  very  long 
time.  The  basic  notion  of  divide  and  conquer 
has  been  around  since  time  immemorial. 
Engineers  take  a  large  system  and  decom¬ 
pose  it  into  subsystems;  when  a  subsystem 
itself  becomes  too  large,  it  is  in  turn  split 
up  in  a  process  called  hierarchical  decomposi¬ 
tion.  The  decomposition  is  done  in  such  a 
way  that  closely  coupled  subsystems  are 
closer  to  each  other,  while  loosely  coupled 
subsystems  are  kept  farther  apart. 

The  problem  in  software  systems  is 
that  it  is  very  easy  for  developers  to  create 
undesirable  couplings  between  subsystems. 
Often  this  is  done  without  an  understand¬ 
ing  of  the  overall  system.  As  a  result,  sub¬ 
systems  become  tightly  coupled  over  time. 
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The  new  approach  has  two  key  ele¬ 
ments:  (1)  a  precise  hierarchical  decompo¬ 
sition  and  (2)  explicit  control  over  allowed 
and  disallowed  dependencies  between  the 
subsystems.  DSM  is  ideal  for  this 
approach  because  it  provides  a  compact 
representation  that  can  easily  scale  up  to 
tens  of  thousands  of  classes  or  files, 
whereas  conventional  box-and-arrow  dia¬ 
grams  become  unusable  for  systems  com¬ 
posed  of  even  a  few  hundred  classes. 

Understanding  DSM 

Brief  History 

DSM  has  traditionally  been  used  to  model 
tasks  involved  in  the  development  of  dis¬ 
crete  products.  The  structure  of  depend¬ 
encies  between  tasks  helps  in  understand¬ 
ing  which  tasks  can  be  done  in  parallel  and 
which  have  to  be  performed  sequentially. 
Cyclic  dependencies  are  indicators  of  pos¬ 
sible  rework  that  may  be  necessary.  Steven 
Eppinger  at  Massachusetts  Institute  of 
Technology’s  Sloan  School  [1]  spearhead¬ 
ed  the  application  of  DSM  within  some  of 
the  largest  companies  in  the  world,  includ¬ 
ing  Boeing,  General  Motors,  Intel,  and 
many  others.  However,  applying  DSM  to 
software  is  new. 

Software  engineers  have  always  under¬ 
stood  the  importance  of  dependencies 
between  modules.  However,  they  have 
tended  to  visualize  the  modules  and  their 
dependencies  as  directed  graphs,  i.e.,  box- 
and-arrow  diagrams.  The  Unified 
Modeling  Language  (UML)  makes  exten¬ 
sive  use  of  directed  graphs,  where  a  vari- 
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ety  of  boxes  and  line  types  are  used  to 
indicate  the  many  types  of  relationships 
that  might  exist  between  different  types  of 
modules.  This  is  useful  for  detailed  design 
but  quickly  becomes  unwieldy  as  the  size 
of  the  application  increases. 

UML  diagrams  provide  limited  value 
in  controlling  the  actual  implementation. 
Indeed,  far  from  controlling  the  design  of 
the  application,  developers  feel  burdened 
when  they  have  to  do  a  round  trip  back  to 
their  UML  models  to  keep  them  synchro¬ 
nized  with  code.  Many  development 
teams  simply  stop  maintaining  their  UML 
models  beyond  the  initial  stages  of  the 
project. 

Using  matrices  in  systems  engineering 
has  a  long  history.  Systems  engineers  have 
used  N- squared  diagrams  to  model  the 
input  and  output  flows  within  their  sys¬ 
tem.  Subsequent  work  by  Baldwin  and 
Clark  at  Harvard  Business  School  [2] 
employing  DSM  to  model  the  evolution  of 
the  computer  industry  brought  it  one  step 
closer  to  the  engineering  of  software. 

The  key  ideas  underlying  our  approach 
[3],  like  most  ideas  in  dependency  tools, 
are  not  new.  The  notion  of  inter-module 
dependency  was  articulated  by  Parnas  in 
his  early  papers  (most  notably  [4]),  and  the 
extraction  and  exploitation  of  dependen¬ 
cies  has  been  the  subject  of  many  more 
recent  projects.  The  potential  significance 
of  the  DSM  for  software  was  noted  by 
Sullivan  et  al.  [5]  in  the  context  of  evaluat¬ 
ing  design  tradeoffs.  Similarly,  Lopes  and 
Bajracharya  [6]  have  also  applied  DSM  to 
study  the  value  of  aspect-oriented  modu¬ 
larization.  MacCormack  et  al.  [7]  have 
applied  the  DSM  to  analyze  the  value  of 
modularity  in  the  architectures  of  Mozilla 
and  Linux. 

Our  approach,  however,  is  the  first 
application  of  DSM  for  the  explicit  man¬ 
agement  of  inter-module  dependencies. 
More  information  about  DSM  and  avail¬ 
able  tools,  including  those  from  Lattix, 
can  be  found  at  <www.dsmweb.org>. 


Figure  1  A-B:  A  Simple  DSM  Before  and  After  Partitioning 
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Making  Sense  of  DSM 

Figure  lA  shows  a  simple  DSM  for  a  sys¬ 
tem  that  consists  of  four  subsystems 
labeled  Modules  A,  B,  C,  and  D.  In  the 
square  matrix,  the  row  and  column  num¬ 
ber  represent  the  same  module  (for  com¬ 
pactness,  only  the  rows  are  labeled).  The 
cells  in  the  grid  show  the  strengths  of  the 
interdependencies  between  each  module. 

The  way  to  read  a  DSM  is  to  read  the 
dependencies  down  a  column.  For 
instance,  column  1  shows  that  Module  A 
depends  on  Module  C  with  dependency 
strength  of  4.  Correspondingly,  reading 
across  row  1  tells  us  that  Module  A  pro¬ 
vides  to  Module  C  and  Module  D  with 
dependency  strengths  of  1  and  2  respec¬ 
tively. 

Traditionally,  DSM  has  often  used  an 
X  to  indicate  a  dependency.  Also  note  that 
a  large  part  of  DSM  literature  reverses  our 
convention  of  how  rows  and  columns  are 
used.  They  use  rows  to  indicate  dependencies 
and  columns  to  indicate  provides.  However, 
we  have  found  that  our  convention  is  a  lit¬ 
tle  more  intuitive  for  software  engineers 
and  is  also  consistent  with  N-squared  dia¬ 
grams. 

Figure  IB  shows  the  DSM  after  parti¬ 
tioning.  Partitioning  is  a  special  operation 
that  reorders  and  regroups  modules.  The 
modules  are  ordered  in  such  a  way  that 
those  modules  that  provide  to  other  mod¬ 
ules  are  placed  at  the  bottom  of  the  DSM, 
while  modules  that  depend  on  other  mod¬ 
ules  are  placed  at  the  top.  If  there  were  no 
dependency  cycles,  this  would  yield  a  lower 
triangular  matrix,  i.e.,  one  without  any 
dependencies  above  the  diagonal. 

Partitioning  also  groups  together  those 
systems  that  have  dependency  cycles.  In 
this  case.  Modules  A  and  C  depend  on 
each  other  and  therefore  have  been 
grouped  together.  This  form  of  the  matrix 
is  called  block  triangular  because  it  has  been 
split  up  into  three  blocks  in  which  there 
are  no  dependencies  above  the  diagonal. 
Layered  systems  are  naturally  expressed  as 
lower  triangular  matrices. 

The  grouping  of  modules  can  also  be 
shown  in  different  ways.  A  new  com¬ 
pound  module  can  be  formed  by  merging 
Modules  A  and  C  as  shown  in  Figure  2 A, 
after  which  the  matrix  becomes  lower  trian¬ 
gular.  Notice  also  that  Module  D  now 
depends  upon  the  new  Module  A-C  with 
dependency  strength  of  5,  which  is  an 
aggregation  of  Module  D’s  dependency 
on  both  Module  A  and  Module  C. 

Furthermore,  the  identities  of  the 
basic  modules  can  still  be  retained  by 
introducing  a  hierarchy,  as  in  Figure  2B,  in 
which  the  grouping  of  A  and  C  is  shown 
by  their  indentation.  The  hierarchical 
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decomposition  shows  that  the  system  has 
been  decomposed  into  three  subsystems: 
Module  D,  Module  A-C,  and  Module  B. 
Module  A-C  is  in  turn  decomposed  into 
Module  A  and  Module  C. 

This  might  seem  like  a  simple  example 
but  hierarchy  is  key  to  scaling  with  DSM. 
Hierarchy  enables  DSM  to  conveniently 
model  systems  with  thousands  of  classes. 
Hierarchy  is  also  important  to  the  succinct 
definition  of  design  rules  that  are  used  to 
specify  allowed  and  disallowed  dependen¬ 
cies.  Design  rules  can  be  used  to  specify 
architectural  patterns  such  as  layering, 
componentization,  external  library  usage, 
and  other  dependency  patterns  between 
subsystems.  When  DSM  is  combined  with 
design  rules,  they  are  called  dependency 
models. 

Defining  a  Dependence  Relationship 

Before  DSM  can  be  applied  to  software,  we 
need  to  define  the  meaning  of  the  statement 
“a  module  is  dependent  upon  another  mod¬ 
ule.”  DSM  is  a  general  device  that  leaves  the 
choice  of  the  definition  of  dependency  to 
its  user.  In  this  case,  we  are  interested  in  the 
architecture  of  the  software  from  a  developer's 
perpective.  This  perspective  is  important  if 
we  are  to  keep  the  design  modular  and  to 


prevent  the  complexity  from  spiraling  out  of 
control  over  time. 

Therefore,  we  say  that  Module  A 
depends  upon  Module  B  if  the  developer 
of  Module  A  needs  to  know  about  the 
behavior  of  Module  B.  The  good  thing 
about  this  definition  for  software  engi¬ 
neering  is  that,  except  in  a  few  cases,  this 
can  generally  be  deduced  by  automatic 
analysis  directly  from  source  code  of  lan¬ 
guages  such  as  Ada,  C/C++,  and  Java. 
The  automatic  analysis  can  be  accom¬ 
plished  by  utilizing  commercially  available 
programs  to  extract  the  dependencies.  For 
newer  languages  such  as  Java  and  C#,  the 
dependencies  can  even  be  extracted  from 
byte  code. 

For  example,  in  Java  we  define  a  Class 
A  as  being  dependent  on  Class  B  if  the 
following  occurs: 

1.  Class  A  inherits  from  Class  B  (imple¬ 
ments  in  the  case  of  an  interface). 

2.  Class  A  calls  a  method  or  a  construc¬ 
tor  in  Class  B. 

3.  Class  A  refers  to  a  data  member  in 
Class  B. 

4.  Class  A  refers  to  Class  B  (e.g.,  as  in  an 
argument  in  a  method). 

The  dependency  strength  can  be  calcu¬ 
lated  in  a  variety  of  ways.  One  is  to  look  at 


Figure  3  A-D:  Architecture  Patterns  in  a  DSM 
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Figure  4A  Figure  4B 


Figure  4  A-B:  DSM  with  Design  Rules 


the  number  of  classes  each  class  depends  fact,  even  when  the  layering  is  imperfectly 
on;  that  number  is  then  aggregated  in  the  implemented  it  can  still  be  recognized  in  a 
hierarchy.  Yet  another  possible  way  is  to  DSM. 

calculate  the  dependency  strength  based  Figure  3A  shows  the  example  of  a  lay- 
on  the  number  of  actual  uses  each  class  ered  system.  The  figure  illustrates  that  the 
makes  of  other  classes;  that  number  is  then  system  consists  of  five  subsystems:  appli- 
aggregated  in  the  hierarchy.  Furthermore,  cation^  models  domain,  framework,  and  util.  The 
it  is  sometimes  useful  to  filter  out  specific  DSM  shows  that  the  layer  at  the  bottom, 
dependencies  such  as  class  references  util,  does  not  depend  on  any  of  the  other 
because  eliminating  them  is  easy.  subsystems;  framework  depends  on  util, 

domain  depends  on  framework  and  util,  and 
Architecture  Patterns  in  a  so  on.  The  lower  triangular  nature  of  the 

Dependency  Model  matrix  makes  it  immediately  apparent  that 

Layering  and  Componentization  ^  layered  system.  Figure  3B  shows  a 

in  a  DSM  strictly  layered  system  where  each  layer 

The  DSM  representation  is  uniquely  suit-  depends  only  on  the  preceding  layer, 
ed  for  representing  certain  architectural  Finally,  Figure  3C  shows  an  imperfect- 
patterns.  Layering  is  one  such  pattern.  In  layered  system.  Since  the  DSM  is  not 


Figure  5:  Conceptual  A.rchitecture  of  A.nt 


lower  triangular  even  after  partitioning,  we 
know  that  there  are  cyclic  dependencies. 
In  this  case,  the  dependencies  in  column  5 
indicate  that  util  has  dependencies  on 
application  and  model  However,  the  imbal¬ 
ance  between  the  strength  of  the  depend¬ 
encies  suggests  that  this  is  an  imperfectly 
layered  system. 

This  discussion  must  not  be  construed 
to  suggest  that  every  software  application 
should  have  a  layered  design.  While  a 
majority  of  large  applications  are  layered, 
DSM  itself  makes  no  prescription  about 
whether  applications  should  always  be  lay¬ 
ered.  However,  for  those  applications  that 
are  layered,  a  representation  based  on  DSM 
is  natural  and  powerful.  As  we  shall  see 
shortly,  design  rules  allow  these  architectur¬ 
al  patterns  to  be  enforced  quite  easily. 

Figure  3D  shows  private  subsystems 
comp-1 ,  comp-2,  and  comp-3  within  subsys¬ 
tem  domain.  The  DSM  reveals  that  nothing 
in  the  system  depends  on  these  private 
subsystems.  Furthermore,  the  DSM  illus¬ 
trates  that  these  private  subsystems  do  not 
depend  on  each  other.  This  suggests  that 
it  is  likely  that  they  could  be  worked  upon 
in  parallel  once  the  framework  that  they 
depend  on  is  in  place. 

Design  Rules:  Enforcing 
Architectural  Patterns 

The  architectural  patterns  that  were 
described  in  the  previous  section  can  be 
enforced  using  design  rules.  The  underly¬ 
ing  concept  of  design  rules  is  quite  simple: 
Once  you  represent  the  architecture  in  a 
hierarchical  DSM,  then  specifying  which 
cells  are  allowed  or  disallowed  from  hav¬ 
ing  dependencies  is  a  natural  extension  to 
document  and  communicate  the  design 
intent. 

When  design  intent  in  the  form  of 
design  rules  is  added  to  a  DSM,  the  result 
is  a  dependency  model.  This  dependency 
model  communicates  not  just  what  the 
actual  dependencies  are  but  also  the 
allowed  and  disallowed  dependencies.  The 
matrix  representation  provides  a  succinct 
and  intuitive  visualization  for  design  rules. 
Figure  4A  shows  a  DSM  with  design  rules 
expressed  as  triangles  in  the  corners  of 
the  cells.  The  upper  left  triangle  repre¬ 
sents  an  allowed  dependency,  while  the 
lower  left  triangle  represents  a  disallowed 
dependency  and  the  upper  right  triangles 
represent  design  rule  violations.  The  use 
of  colors  can  enhance  usability;  for 
instance,  the  triangles  can  be  colored 
green,  yellow,  or  red  to  indicate  an  allowed 
dependency,  a  disallowed  dependency,  or 
a  violation,  respectively. 

If  the  DSM  grid  represents  the  design 
space,  the  design  rules  qualify  that  design 
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space  by  specifying  which  parts  of  the 
design  space  are  allowed  to  have  depend¬ 
encies  and  which  are  disallowed.  In  a  sys¬ 
tem  with  1,000  classes,  a  fully  expanded 
DSM  grid  has  one  million  cells.  Since  each 
cell  represents  design  intent,  there  are  one 
million  possible  design  rules.  Fortunately, 
classes  interact  with  each  other  in  fairly 
regular  ways.  Layers  are  just  one  example 
of  how  classes  within  each  layer  interact 
with  classes  in  other  layers.  For  a  five-layer 
system,  just  five  rules  are  needed  to  speci¬ 
fy  their  interaction  regardless  of  the  num¬ 
ber  of  classes  within  the  system.  Figure 
4B  shows  the  design  rules  for  enforcing 
the  layers  in  such  a  system.  Note  that 
showing  only  the  cannot-use  rules  tends 
to  make  the  DSM  more  readable. 

Software  degrades  from  release  to 
release  because  implicit  design  rules  such 
as  layering  are  violated.  Previously,  archi¬ 
tects  did  not  have  a  way  to  specify,  track, 
or  enforce  these  implicit  rules.  Depen¬ 
dency  models  now  offer  the  potential  for 
maintaining  the  architecture  over  succes¬ 
sive  revisions  of  the  life  cycle  by  specify¬ 
ing  rules  explicitly  that  define  the  accept¬ 
able  and  unacceptable  dependencies 
between  subsystems.  In  cases  where  archi¬ 
tecture  has  evolved  and  design  rules  need 
to  be  changed,  violations  can  actually 
make  architectural  evolution  explicit  for 
the  entire  development  team 

Tracking  Architecture 
Evolution  in  a  Dependency 
Model 

We  will  apply  the  dependency  model 
approach  to  Ant,  a  popular  Java  build  util¬ 
ity.  Ant  is  an  open  source  application  that 
is  used  by  developers  to  compile,  create  jar 
files,  build  executables,  and  other  sundry 
development  tasks. 

One  of  the  principal  reasons  for  the 
success  of  Ant  has  been  the  notion  of 
tasks.  Tasks  are  named  entities  that  do  the 
actual  work  and  utilize  the  common  Ant 
framework  for  doing  so.  Examples  of 
tasks  are  compile^  copy^  make  directory^  and  cre¬ 
ate  jar  file.  Over  time,  a  large  number  of 
tasks  have  been  created  by  independent 
developers  all  over  the  world.  This  has 
worked  well  because  the  architects  of  Ant 
had  the  foresight  to  keep  the  tasks  in  a 
layer  separate  from  the  framework. 

Figure  5  illustrates  this  conceptual 
architecture.  Ant  has  been  decomposed 
into  three  layers:  taskdefs,  ant^  and  util.  The 
taskdefs  layer  contains  the  tasks,  the  ant 
layer  contains  the  framework,  and  the  util 
layer  contains  utilities  that  could  be  used 
by  both  the  framework  and  tasks. 

The  dotted  lines  between  the  subsys¬ 


tems  illustrate  allowed  dependencies, 
while  the  dotted  lines  with  a  disallow  sym¬ 
bol  illustrate  disallowed  dependencies. 
The  layered  approach  reduces  complexity 
and  minimizes  the  likelihood  that  a  bug 
introduced  in  the  development  of  a  task 
will  affect  the  framework,  that  in  turn 
could  affect  other  tasks. 

The  DSM  for  Ant  Vers.  1.4.1  in  Figure 
6  shows  that  Ant  has  three  distinct  layers. 
However,  the  Ant  framework  represented 
by  the  middle  subsystem  is  largely  mono¬ 
lithic.  For  Vers.  1.4.1,  it  was  not  a  signifi¬ 
cant  issue  because  the  Ant  framework  was 
quite  small  at  the  time.  We  also  note  that 
the  Java  package  names  do  not  reflect  the 
layering. 

By  comparison,  the  DSM  for  the  cur¬ 
rent  version  of  Ant  in  Figure  7  shows  that 


architectural  violations  have  begun  to 
creep  in  as  the  Ant  framework  has 
become  dependent  on  the  taskdefs  layer. 
Further,  the  application  is  now  consider¬ 
ably  larger  while  the  Ant  framework  con¬ 
tinues  to  be  largely  monolithic.  However, 
it  should  be  noted  that  the  architecture  of 
Ant  is  still  not  as  bad  as  we  have  seen  in 
many  other  commercial  systems  that 
receive  less  scrutiny  than  Ant. 

Frequently,  systems  become  so  com¬ 
plex  that  development  teams  suggest  a 
rewrite.  This  is  inherently  a  high-risk  deci¬ 
sion  since  there  is  no  way  to  guarantee  that 
the  new  system  will  not  suffer  from  simi¬ 
lar  problems  of  complexity.  The  depend¬ 
ency  model  already  gives  us  guidance 
about  which  dependencies  to  fix  and  their 
relative  priority.  This  analysis  of  the 


Figure  7:  Dependency  Model  for  Ant  Version  1 .6.1 
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dependencies  reveals  where  the  architec¬ 
ture  is  really  broken  and  whether  remedia¬ 
tion  requires  a  complete  rewrite  or  just  a 
fix  to  the  problematic  dependencies.  Note 
that  additional  analysis  using  the  DSM  can 
easily  be  conducted  to  explore  alternate 
organization  of  the  architecture,  and  how 
the  framework  itself  can  be  split  up  so  it  is 
no  longer  monolithic. 

Dependency  models  can  also  be 
extended  to  specify  the  dependencies  of 
each  subsystem  upon  external  libraries. 
First,  the  dependency  model  is  examined 
to  see  what  external  libraries  are  used  and 
which  subsystems  use  them.  For  instance, 
in  Ant  Vers.  1.6.1,  we  find  that  some  of 
the  external  libraries  in  use  include 
org.apache.hcel^  org.apache.bsp  and  org. apache, 
xml.  Design  rules  can  then  be  used  to 
specify  the  subsystems  that  are  allowed  to 
use  these  external  libraries.  Controlling  the 
use  of  external  libraries  can  pay  rich  divi¬ 
dends.  In  addition  to  helping  to  maintain 
architectural  integrity,  segregating  the  use 
of  external  libraries  can  also  ease  the  job 
of  migrating  to  new  technologies  as  they 
become  available. 

Architecture  Management  as 
Part  of  CMMI 

The  dependency  model  provides  a  new 
way  to  define  and  enforce  architecture  for 
software  engineering  process  initiatives 
such  as  Capability  Maturity  Model®  Inte¬ 
gration  (CMMI®).  A  shared  understanding 
of  the  architecture  and  managing  its 
change  can  significantly  improve  the 
results  that  can  be  derived  from  these 
CMMI  specific  process  areas: 

•  Requirements  Development:  Base¬ 
line  conceptual  architecture  and 
dependency  model  for  inclusion  in  the 
technical  data  package. 

•  Technical  Solution:  Assess  architec¬ 
tural  alternatives,  formalize  precise 
subsystem  decomposition,  and  define 
the  dependencies  between  the  decom¬ 
posed  subsystems.  Measure  and  verify 
architectural  conformance. 

•  Product  Integration:  Identify  com¬ 
ponents  for  product  line  architectures. 
Remove  redundancies.  Improve  testa¬ 
bility  of  products. 

•  Project  Planning:  Estimate  impact  of 
new  feature  requests  and  track 
progress  against  architectural  changes. 

•  Decision  Analysis  and  Resolution: 
Document  rationale  for  architectural 
changes,  understand  risks,  evaluate, 
and  estimate  impact  of  proposed 
changes. 

®  Capability  Maturity  Model  and  CMMI  are  registered  in 
the  U.S.  Patent  and  Trademark  Office  by  Carnegie 
Mellon  University. 


In  addition,  the  dependency  model 
approach  provides  new  means  to  make 
architecture  management  part  of  the 
CMMI  generic  processes.  It  can  be  used  to 
manage  architecture  configurations;  in¬ 
volve  stakeholders;  and  to  evaluate,  moni¬ 
tor,  and  control  the  architecture. 

Conclusion 

Architecture  is  integral  to  software  quality. 
Unless  the  architecture  is  explicitly 
defined,  communicated,  and  controlled,  it 
will  degrade  as  the  complexity  increases 
through  the  life  cycle.  The  dependency 
model  is  a  powerful  new  way  to  manage 
the  architecture  of  software  applications. 

It  is  highly  advisable  that  architecture 
be  tested  automatically  as  part  of  regular 
builds.  Inadvertent  violations  can  then  be 
fixed  immediately,  avoiding  expensive 
remediation  later  in  the  development  cycle. 
This  approach  is  lightweight  —  dependency 
models  can  be  checked  and  updated  auto¬ 
matically  with  intervention  being  required 
only  when  violations  are  detected. ♦ 
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UML  Design  and  Auto-Generated  Code: 
Issues  and  Practical  Solutions 


Ilya  Lipkin  and  Dr.  A.  Kris  Huber 
YLill  A.ir  Force  Base 

This  article  presents  issues  encountered  as  well  as  practical  solutions  to  using  the  Unified  Modeling  Fanguage  (UMF)  for  design 
and  automatic  code  generation.  Topics  presented  include  general  issues  found  with  UML  on  a  real-time  systems  design  project. 


This  article  is  based  on  experience  gained 
during  the  early  history  of  a  project 
being  worked  on  at  Hill  Air  Force  Base, 
Utah.  One  of  the  customer  requirements  on 
this  project  was  a  specific  development  tool 
based  on  Unified  Modeling  Language 
(UML)  Version  1.3,  namely  Rational  Rose 
RealTime  (RoseRT). 

The  project  issues  and  solutions  pre¬ 
sented  in  this  article  are  from  the  real-time 
control  system.  The  configured  software 
items  consist  of  software  design  elements 
expressed  in  UML  from  which  C++  code 
can  be  automatically  generated.  The  obser¬ 
vations  presented  in  this  article  do  not  nec¬ 
essarily  apply  to  all  UML-based  develop¬ 
ment  tools,  but  the  authors  have  made  an 
attempt  to  raise  a  few  issues  of  general 
interest  to  those  involved  in  similar  projects. 

Overview  of  UML 

UML  is  a  modeling  language  developed  by 
Grady  Booch,  James  Rumbaugh,  and  Ivar 
Jacobson,  and  many  other  contributors  to 
the  Object  Management  Group  (OMG). 
The  focus  of  UML  is  to  model  systems 
using  object-oriented  concepts  and  method¬ 
ology.  UML  consists  of  a  set  of  model  ele¬ 
ments  that  standardize  the  design  descrip¬ 
tion.  These  elements  include  a  number  of 
fundamental  model  elements  and  modeling 
concepts,  in  addition  to  views  that  allow 
designers  to  examine  a  design  from  different 
perspectives,  and  diagrams  to  illustrate  the 
relationships  among  model  elements. 

Several  views  such  as  Use-Case  View, 
Logical  View,  Component  View,  Concur¬ 
rency  View,  and  Deployment  View  create  a 
complete  description  of  the  system  design. 
Within  each  view,  an  organized  set  of  dia¬ 
grams  and  other  model  elements  are  visible. 
Diagrams  include  use-case  diagrams,  class 
diagrams,  object  diagrams,  sequence  dia¬ 
grams,  collaboration  diagrams,  statechart 
diagrams,  activity  diagrams,  component  dia¬ 
grams,  and  deployment  diagrams.  Some  key 
primitive  model  elements  are  states,  transi¬ 
tions,  messages,  classes,  class  roles,  attrib¬ 
utes,  and  operations  [1]. 

The  UML  language  is  complete  enough 
that  it  offers  the  exciting  ability  to  allow  the 
creation  of  auto-generated  code  that  imple¬ 
ments  the  design.  The  code  can  be  generat¬ 


ed  from  the  system  description  of  the 
model  through  the  use  of  diagrams  and 
other  model  elements. 

UML  Elements  for  Real-Time 
Systems  Design 

Designing  real-time  systems  is  challenging. 
In  UML,  an  actire  class  model  element  was 
introduced  to  address  this  challenge.  The 
purpose  of  this  element  was  to  help  simpli¬ 
fy  both  the  design  and  the  implementation. 

The  active  class  model  element  consists 
of  a  communication  structure  description 
and  a  behavioral  description.  The  communi¬ 
cation  structure  is  described  using  a  collab¬ 
oration  diagram  that  shows  the  ports 
through  which  it  sends  and  receives  mes¬ 
sages  to  and  from  other  active  classes.  The 
behavior  is  described  using  a  statechart  dia¬ 
gram  that  shows  how  the  active  class  acts 
and  reacts  to  its  environment^  In  other 
words,  the  active  class  is  a  standalone  capsule 
of  software  that  talks  to  its  environment 
through  ports  (specified  in  the  structure  dia¬ 
gram),  and  performs  actions  as  it  transitions 
through  a  sequence  of  states  (specified  by 
the  statechart  diagram). 

The  characteristics  of  a  run-time  sys¬ 
tem  (RTS)  object  and  the  UML  active  class 
were  determined  to  simplify  the  process  of 
real-time  software  design  and  implementa¬ 
tion.  In  addition,  by  encapsulating  calls  to 
the  operating  system  of  the  target  plat¬ 
form  within  the  RTS,  the  auto-generated 
implementation  of  the  UML  design  can  be 
made  largely  platform-independent.  Real¬ 
time  application  design  with  UML  is  dis¬ 
cussed  in  [2]. 

UML  Issues  and  Practical 
Solutions 

While  working  on  the  project,  several  prob¬ 
lems  dealing  with  UML  for  design  and 
implementation  were  encountered.  Below 
are  some  of  the  issues  related  to  UML 
design  and  implementation.  These  issues, 
some  solutions,  and  open  questions  will  be 
presented  using  small  illustrations. 

Issue  No.  I :  State  Diagram  Clutter 

When  designing  with  UML,  it  is  easy  for  a 
developer  to  put  too  much  information 
into  a  single  diagram.  When  this  happens. 


information  overload  will  make  the  design 
difficult  to  understand  and  maintain. 

Example 

It  is  possible  to  describe  the  behavior  of 
an  entire  design  in  a  single  UML  statechart 
diagram.  To  demonstrate  the  potential  for 
diagram  clutter,  let  us  consider  this  simple 
case:  There  is  a  system  model  that  will  take 
user  input,  button  press  (an  event),  and 
convert  it  to  a  textual  presentation  of  the 
button  press  to  be  displayed  on  screen.  An 
all-UML  solution  for  this  simple  case  is 
shown  in  Figure  1 . 

The  design  consists  of  a  set  of  three 
choice  points  and  two  states  with  transitions 
between  them.  Each  choice  point  represents 
a  decision  to  be  made  when  an  event-trig¬ 
gered  transition  has  occurred.  State  SI  rep¬ 
resents  the  entry  into  the  system  model  and 
S2  is  the  final  state  of  the  system  model. 

Since  this  system  model  is  designed 
with  RoseRT  UML  elements,  the  state 
machine  solution  is  a  fully  functional 
implementation  and  design.  For  imple¬ 
mentation,  C++  is  auto-generated  from 
the  UML  design.  This  simple  design  solu¬ 
tion,  although  straightforward,  is  some¬ 
what  hard  to  understand  from  the  state- 
chart  diagram  in  Figure  1 .  This  is  because 
the  view  of  the  system  is  cluttered  by  tran¬ 
sition  labels  and  a  large  number  of  UML 
elements  presented  in  a  small  visual  area. 

Practical  Solutions 

In  Figure  2  (see  page  14),  the  solution  to  the 
same  problem  is  shown,  but  utilizing  a 
mixed  UML  and  C++  approach  to  simplify 
the  model.  The  action  code  in  the  transition 
Event  woUdi  perform  the  logic  implemented 
by  the  choice  points  (circles)  in  Figure  1,  as 

Figure  1:  All-UML  Solution 
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Design 


Figure  2:  Combined  UMLj C++  Solution 
illustrated  by  the  following  pseudocode: 


if(Event1)  then 

display  stringl 
else  if(Event2)  then 
display  string2 
else  if(Event3)  then 
display  strings 

This  solution  moves  logic  that  is 
straightforward  and  redundant  into  the  state 
transition  between  states  SI  and  S2.  In  addi¬ 
tion,  it  also  keeps  the  same  overall  logic  of 
the  UML  statechart  of  Figure  1 . 

Another  benefit  to  the  UML  and  C++ 
solution  is  that  the  size  of  the  system  model 
can  be  reduced.  The  Figure  1  solution  pro¬ 
duces  an  implementation  consisting  of  315 
Hnes  of  auto-generated  code  and  three  lines 
of  user  code  (code  that  is  inserted  by  the  user 
and  copied  verbatim  by  the  code  generator). 
On  the  other  hand,  the  mixed  UML/ C++ 
solution  in  Figure  2  produces  an  implemen¬ 
tation  consisting  of  21 5  Hnes  of  auto-gener¬ 
ated  code  and  14  Hnes  of  user  C++  code. 

This  example  demonstrates  that  the 
size  of  the  auto-generated  code  can  be 
reduced  through  using  a  mixed  UML/ 
C++  design  approach.  The  code  efficien¬ 
cy  and  maintainabiHty  also  seem  to  be 
improved  in  this  case,  although  this  will 
not  be  true  for  aU  designs.  The  maintain¬ 
abiHty  of  a  UML-based  software  object 
will  depend  upon  several  factors,  including 
the  maintenance  team’s  relative  proficien¬ 
cy  with  UML  compared  to  the  underlying 
implementation  language. 

An  alternate  method  of  reducing  the 
number  of  visual  elements  on  a  model  dia¬ 
gram  is  to  design  hierarchical  state 
machines.  If  hierarchal  statecharts  are  sup¬ 
ported  by  the  design  tool,  multiple  states  can 
be  combined  to  create  a  clearer,  high-level 
statechart  containing  fewer  states.  This 


approach  to  reducing  visual  elements  has  an 
additional  benefit  of  increased  portabiHty  of 
the  design,  but  may  not  achieve  the  imple¬ 
mentation  efficiency  of  the  combined 
UML/C++  approach. 

Guideline 

Although  UML  is  very  flexible,  some  imple¬ 
mentation  and  design  considerations  should 
be  addressed  through  conventional  means 
by  either  manuaHy  coding  or  using  system 
flow  diagrams  outside  of  UML  [3]. 

It  is  important  to  keep  the  number  of 
states  and  transitions  to  a  minimum.  As  the 
model  complexity  increases,  understanding 
of  the  design  can  be  decreased  due  to  clut¬ 
ter  in  the  design  diagrams.  The  efficiency 
of  the  auto-generated  implementation  of 
the  design  can  also  be  reduced.  Depending 
upon  the  need  for  implementation  efficien¬ 
cy,  and  the  team  member  famiHarity  with 
UML,  an  appropriate  design  philosophy 
should  be  estabHshed  for  the  project. 

/ssue  No.  2:  UML  Metrics 

The  authors  were  not  aware  of  any  useful 
software  size  metrics  that  could  be  used 
with  UML  models.  Using  the  source  Hnes  of 
code  (SLOG)  metric  on  auto-generated 
code  tended  to  overemphasize  the  UML 
portion  of  a  mixed  UML/ C++  model  (with 
the  UML  portion  being  auto  generated  and 
the  C++  portion  being  user  code).  Metrics 
were  needed  both  for  project  estimation  and 
project  tracking. 

Discussion 

Many  design  rules  have  been  proposed  for 
judging  UML  design  quaHty  [4].  However,  it 
is  hard  to  know  how  to  track  effort  used  on 
developing  software  using  such  metrics. 
Obviously,  SLOG  for  auto-generated  code 
size  could  be  misleading,  but  to  be  feasible, 
the  project  tracking  and  estimation  tools 
often  require  using  a  scalar  metric  Hke 
SLOG  rather  than  a  vector  of  metrics.  The 
chaUenge  is  to  correlate  the  size  metric  to 
the  amount  of  development  effort  required 
for  design  and  implementation  of  the  soft¬ 
ware.  Experimentation  with  the  SLOG  met¬ 
ric  upon  auto-generated  code  seemed  to 


overemphasize  the  UML  portion  of  a  mixed 
UML/C++  model. 

Example 

How  do  we  judge  the  total  size  of  the  mod¬ 
els  of  Figures  1  and  2? 

Practical  Solution 

To  arrive  at  the  solution  presented  below,  it 
was  necessary  to  experiment  with  more  than 
one  metric  for  total  size.  One  of  the  possi¬ 
ble  methods  is  iHustrated  in  the  solution  of 
issue  No.  1:  Measure  the  auto-generated 
code  separately  from  the  user  code  that  is 
manuaHy  maintained.  This  approach  is  ade¬ 
quate  for  some  purposes,  but  in  other  situa¬ 
tions,  a  metric  is  needed  that  captures  the 
size  in  a  single  number. 

To  remedy  shortfaHs  of  the  previous 
approach,  a  second  metric  was  defined  that 
consists  of  a  single  number  to  represent 
model  size.  A  utiHty  tool  was  developed  that 
could  traverse  the  model  and  provide  a  total 
count  of  several  of  the  key  UML  model  ele¬ 
ments.  Based  on  counts  of  model  elements 
and  user  code  SLOG,  this  metric  could  be 
calculated  as  a  weighted  sum.  The  weights 
shown  in  the  second  column  of  Table  1 
were  used  to  give  a  size  estimate  in  terms  of 
implementation  units  (lU). 

Using  this  UML  metric,  the  size  of  the 
models  in  Figures  1  and  2  are  calculated 
from  the  weighted  sum  of  their  model  ele¬ 
ments  to  be  107  and  52  lU,  respectively.  The 
weights  associated  with  this  metric  were 
estimated  subjectively  based  on  the  RoseRT 
user  interface  for  each  of  the  model  ele¬ 
ments.  The  resulting  lU  metric  has  a  level  of 
detail  similar  to  SLOG,  and  the  measure  may 
be  thought  of  as  a  SLOG-equivalent  metric. 
The  weights  associated  with  this  metric  have 
yet  to  be  fuHy  substantiated  due  to  insuffi¬ 
cient  historical  data  for  the  project.  For  this 
reason,  project  history  data  is  maintained  in 
a  raw  format  so  that  new  weights  (and  even 
new  metrics)  can  be  appHed  to  the  entire 
project  history. 

This  second  metric  for  estimating  the 
size  of  a  combined  UML/G++  model/ 
implementation  is  similar  in  spirit  to  the 
function  points  approach.  In  place  of  logi¬ 
cal  or  functional  elements,  UML  model  ele¬ 
ments  were  given  SLOG-equivalent  weights. 

Guideline 

It  is  best  to  find  a  metric  that  correlates 
weH  to  the  quantity  desired.  Employ  UML 
design  tools  that  contain  rich  appHcation 
programming  interfaces  (APIs)  to  faciH- 
tate  development  of  utiHties  that  automate 
the  process  of  metrics  calculation. 
Gollecting  data  in  a  raw  format  can  faciH- 
tate  adjustment  or  customization  of  the 
metrics. 


Table  1 :  Weights  and  Counts  for  Kej  UMh  Model  Elements 


Model  Element 

Weight  (lU) 

Counts  for  Figure  1 

Counts  for  Figure  2 

States^ 

6 

5 

2 

Transitions 

6 

10 

2 

Capsule  Roles 

9 

1 

1 

Ports 

5 

1 

1 

Attributes 

1 

0 

0 

Operations 

4 

0 

0 

Signals 

2 

0 

0 

User  Code 

1 

3 

14 

TOTAL  (lU) 

107 

52 
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Issue  No.  3:  Documentation  for 
Graphical  Elements 

Although  UML  implements  graphical  meth¬ 
ods  of  presenting  software  solutions,  it  is 
very  challenging  to  create  a  self-document¬ 
ing  model.  Traditional  documentation  of 
the  graphical  model  is  still  needed. 

Discussion 

Many  developers  consider  documentation 
to  be  the  least  favorable  task  of  any  new 
design.  UML,  combined  with  automatic 
report  generation  capability  in  the  tool, 
allows  the  possibility  of  design  and  imple¬ 
mentation  to  be  self-documenting.  When 
using  UML  for  the  design  task,  the  designer 
must  create  a  set  of  UML  diagrams  and 
other  graphical  information  such  as  states, 
transitions,  and  illustrations  of  the  struc¬ 
tured  relationship  among  objects.  The  final 
product  is  a  model  that  contains  design 
information  in  a  graphical  format  that 
should  be  suitable  for  documentation. 
Ideally  if  the  design  is  well  drawn,  then 
graphical  information  is  actually  usable  for 
documentation,  and  a  lot  of  time  and  effort 
savings  can  be  realized. 

Example 

Figure  1  is  an  example  of  a  UML  model  that 
is  not  self-documenting.  Looking  at  this  fig¬ 
ure,  several  questions  can  be  raised.  What  do 
choice  points  do?  What  is  being  compared? 
What  do  frue  and /a/se  labels  mean?  What  do 
State  SI  and  State  S2  represent?  The  answer 
to  these  questions  is  that  SI  is  an  initial  state 
and  S2  is  the  final  state.  The  choice  points 
are  the  logic  to  set  the  string  to  be  displayed 
based  on  events  that  occur.  True  and  /a/se 
label  the  condition-dependent  transitions 
from  the  choice  points. 

UML  tools  can  produce  a  sequence 
diagram  from  a  statechart  diagram,  as  well 
as  generate  a  number  of  documentation 
reports.  These  typically  exclude  any  user 
code  implementation  documentation. 
Project  experience  found  customization  of 
documentation  reports  to  be  non-trivial. 

Practical  Solution 

In  the  example  of  Figure  1,  a  set  of  sup¬ 
porting  documentation  is  still  necessary  to 
accompany  a  graphical  design.  Although 
this  seems  to  be  a  very  obvious  observation, 
the  project  currently  being  worked  on  had 
omitted  to  document  the  graphical  design. 
As  a  result,  the  loss  in  ability  to  understand 
and  maintain  statecharts  had  increased  cost 
and  delayed  schedule.  In  addition,  maintain¬ 
ability  of  the  real-time  system  had  been 
drastically  reduced.  Although  prudent 
choice  of  names  for  the  model  elements  can 
help  make  the  diagrams  more  self-docu¬ 
menting,  the  use  of  UML  use  cases  and 


their  relationship  to  the  graphical  state-chart 
solutions  must  be  documented  rather  than 
assumed  to  be  self-documenting.  Software 
developers  must  come  up  with  a  set  of  doc¬ 
umentation  that  bridges  the  link  between 
use  cases  and  their  UML  graphical  represen¬ 
tations.  The  final  gap  to  be  filled  is  the  aug¬ 
mentation  of  documentation  generated 
automatically  from  UML  with  manual 
description  for  user  code  and  how  it  fits 
with  design  implementation. 

Guideline 

Although  UML  presents  design  visually, 
comments  on  the  states  or  any  other  model 
elements  are  still  needed.  These  comments 
clarify  the  overall  solution  and  explain  some 
of  the  design  choices  of  the  model  diagram 
[5].  Self-documenting  features  of  UML  are 
still  no  substitute  for  design  notes  or  addi¬ 
tional  supporting  documentation  on  design 
decisions. 

Issue  No.  4:  Design  Portability 
Between  UML  Tools  (Open  Question) 

Using  custom  (i.e.,  nonstandard)  features  of 
UML  tools  reduces  portability  of  a  design 
to  other  UML-compliant  development 
tools. 

Example 

RoseRT  had  introduced  additional  concepts 
into  UML  to  accommodate  the  needs  of  the 
real-time  environment,  and  to  allow  for  a 
development  tool  to  produce  auto-generat- 
ed  code  solutions.  One  of  the  new  concepts 
to  UML  introduced  by  RoseRT  was  a  struc¬ 
ture  diagram.  Figure  3.  Structure  diagrams 
are  used  in  RoseRT  to  link  capsules  togeth¬ 
er  in  a  coherent  way. 

Practical  Solution 

Unfortunately,  there  is  no  straightforward 
solution  for  this  problem;  the  only  thing  that 
can  be  used  is  a  set  of  mitigation  strategies. 
One  of  those  mitigation  strategies  was  the 
choice  of  product  itself  Although  this  was 
done  at  the  program  office,  the  UML  imple¬ 
mentation  chosen  was  from  the  primary 
contributors  to  the  UML  standard.  Struc¬ 
ture  diagrams  were  not  part  of  UML  initial¬ 
ly,  but  rather  RoseRT’s  structure  diagrams 
were  based  on  the  UML  1.3  collaboration 
diagram.  Another  notable  difference  is  the 
notion  of  capsules,  which  are  presented  in 
Figures  1  and  2.  Capsules  are,  in  essence, 
UML  1.3  active  classes  and  will  be  part  of 
UML  2.0  as  structured  classes. 

Another  strategy  is  to  avoid  external  API 
calls  in  the  user  code  portion  of  the  model, 
as  it  will  make  the  design  less  portable  to 
other  UML  solutions.  Also,  the  RoseRT 
UML  tools  come  with  a  set  of  custom  API 
calls  that  can  be  used  to  enhance  design  and 


Figure  3:  Structure  Diagram 


development  efforts,  but  it  is  best  to  avoid 
using  them  if  design  portability  is  an  issue. 

Guideline 

Some  of  the  UML  development  tools  offer 
specialized  controls  or  functionality  that  do 
not  exist  in  other  tools.  It  is  a  good  idea  to 
explore  means  for  design  using  standardized 
UML  components  rather  than  customized 
ones.  This  requires  the  design  team  to 
become  familiar  with  the  UML  standards  to 
recognize  and  avoid  nonstandard  items, 
thereby  providing  portability  across  devel¬ 
opment  tool  vendors. 

Issue  No.  5;  Cross  Language  and 
Cross  Platform  Development 

Target  languages  or  their  compilers  can 
have  platform- specific  features  that  defeat 
the  portability  of  a  mixed  UML/user- 
code  solution. 

Discussion 

One  of  the  advantages  of  UML  develop¬ 
ment  is  that  it  is  language-neutral,  and  plat¬ 
form-independent.  Using  UML,  it  is  possi¬ 
ble  to  disconnect  the  design  from  possible 
issues  of  implementation  that  are  based  on 
the  choice  of  source  code  language.  In  addi¬ 
tion,  the  ability  to  take  UML  design  as  is, 
and  to  auto-generate  source  code  from  it, 
allows  for  the  creation  of  implementation 
directly  from  the  design  [6].  Due  to  UML 
being  language  neutral,  the  solution  will  not 
change  if  the  target  language  is  C/C++, 
Java,  or  anything  else  [7].  In  addition,  if  one 
of  the  requirements  is  to  maintain  the  same 
code  in  two  languages,  it  becomes  simpler 
to  have  bug  reports  and  fixes  done  in  one 
place  rather  then  two. 

The  ability  to  create  a  design  that  is  plat¬ 
form-independent  provides  a  set  of  unique 
opportunities  and  challenges.  Cost  may  be 
reduced  by  enabling  a  portion  of  testing  to 
take  place  on  a  development  platform  that 
does  not  necessarily  include  a  simulation  of 
the  target  environment.  Multi-platform 
testing  may  have  a  beneficial  effect  of  find¬ 
ing  some  defects  that  would  otherwise  be 
masked  on  one  of  the  individual  platforms. 
The  challenge  of  platform-independent 
design  is  to  ensure  that  special  require¬ 
ments  of  the  final  target  environment  are 
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Design 


State  No.,  Name 

Description 

Attributes 

Initial 

System  not  running 

Timer  event  set  to  30  seconds 

Green 

On  timer  time-out  event  go  to(goYellow)  Yellow 

Timer  event  set  to  45  seconds 

Yellow 

On  timer  time-out  event  go  to(goRed)  Red 

Timer  event  set  to  1 0  seconds 

Red 

On  timer  time-out  event  go  to(goGreen)  Green 

Timer  event  set  to  30  seconds 

Table  2:  State  Specification  Template 


models,  extra  care  must  be  taken  to  avoid  a 
platform- specific  syntax  in  the  implementa¬ 
tion  language. 


Figure  4:  Working  UMT  Design  and 
Implementation  Solution  for  Traffic  Tight 

being  considered  in  the  design  of  the  user 
code  portion  of  the  UML  model. 

Example 

A  traffic  light  design  scenario  can  be  used 
to  demonstrate  the  ability  to  have  a  cross¬ 
language  and  cross-platform  development. 
This  small  UML  design  example  shows 
both  design  and  implementation. 

Requirements  for  traffic  light  are  pre¬ 
sented  below.  The  traffic  light  has  three 
colors:  red,  yellow,  and  green.  To  change 
from  green  to  yellow,  an  event  of  time 
expiring  is  needed.  The  events  always  hap¬ 
pen  in  a  fixed  sequence  of  green  to  yellow 
to  red.  It  is  not  allowed  to  go  from  green 
to  red,  for  example.  The  State 
Specification  Template  (Table  2)  is  used  to 
describe  a  sequence  of  state-change 
events  [8].  Timer  events  are  written  as 
generic  RoseRT  descriptions  for  each 
event  as  “timer.infor  min  (timeout);”  this  is 
the  only  line  of  code  that  is  written  for  the 
entire  design  and  implementation. 

Practical  Solution 

The  UML  solution  in  Figure  4  is  complete¬ 
ly  language-  and  platform-neutral.  There  is 
no  user  code  associated  with  it  that  is  lan¬ 
guage-  or  platform-specific.  Therefore  it  is 
possible  for  an  auto-code  generation  engine 
to  translate  the  UML  to  a  destination  lan¬ 
guage  or  platform  of  choice. 

Guideline 

When  implementing  UML  design,  it  is  best 
to  avoid  considerations  of  how  code  gener¬ 
ation  will  translate  UML  to  a  target  lan¬ 
guage  or  system  platform  for  the  auto-gen¬ 
erated  portion  of  the  solution.  However, 
when  entering  user  code  into  mixed  UML 


Conclusion 

UML  design  introduces  new  and  unex¬ 
plored  paradigms  that  can  either  simplify 
the  task  or  make  it  overly  complex.  It  is 
important  to  adhere  to  proven  methods 
and  concepts  to  utilize  what  is  available. 
Practical  solutions  and  guidelines  related 
to  diagram  clutter,  UML  metrics,  docu¬ 
mentation,  design  portability,  and  cross¬ 
language/  cross-platform  development 
presented  in  this  article  are  the  tip  of  an 
iceberg  in  a  great  sea  of  development. ♦ 
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Notes 

1.  In  the  RoseRT  tool,  active  classes  are 
caked  capsules;  the  associated  collabo¬ 
ration  diagrams  are  called  structure  dia¬ 
grams. 

2.  Choice  points  are  considered  pseu¬ 
dostates  that  are  counted  as  states  when 
calculating  this  metric. 
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UML  2.0-Based  Systems  Engineering  Using  a 
Model-Driven  Development  Approach 

Dr.  Hans-Peter  Hoffmann 
1-L.ogix  Inc. 

More  and  more,  systems  engineers  are  turning  to  the  Unified  Modeling  Uanguage  (UMU)  to  specify  and  structure  their  sys¬ 
tems.  This  has  many  advantages,  including  verifiability  and  ease  of  passing  off  information  to  other  engineering  disciplines, 
particularly  software.  This  article  describes  a  UMT  2.0 -based process  that  systems  engineers  can  use  to  capture  requirements 
and  specify  architecture.  The  process  uses  the  UMT  exclusively  for  the  representation  and  specification  of  system  characteris¬ 
tics.  Essential  UMT  artifacts  include  use-case  diagrams,  sequence  diagrams,  activity  diagrams,  state-chart  diagrams,  and 
structure  diagrams.  The  process  is  function-driven  and  is  based  heavily  on  the  identification  and  elaboration  of  operational 
contracts,  a  message-based  inteface  communication  concept.  The  outlined  process  has  been  applied  successfully  at  various  cus¬ 
tomer  sites.  It  is  assumed  that  the  reader  is  familiar  with  the  basics  of  UMT. 


For  many  years,  software  engineers 
have  successfully  applied  the  Unified 
Modeling  Language  (UML)  to  model- 
based  software  engineering.  There  have 
been  several  attempts  to  introduce  UML 
and  the  underlying  object-oriented  meth¬ 
ods  to  systems  engineering  to  unify  the 
overall  development  process.  However, 
many  systems  engineers  continue  to  use 
classically  structured  analysis  techniques 
and  artifacts  to  define  system  require¬ 
ments  and  designs. 

One  reason  for  this  could  be  that  sys¬ 
tems  engineering  is  mostly  driven  by 
functional  requirements.  Speaking  in 
terms  of  system  functionality  is  still  con¬ 
sidered  the  most  natural  way  of  express¬ 
ing  a  design  by  most  of  the  domain 
experts  involved  in  the  early  phases  of 
system  development  (electrical  engi¬ 
neers,  mechanical  engineers,  test  engi¬ 
neers,  marketing  personnel,  and,  of 
course,  customers).  Given  this,  the  only 
way  to  unify  the  overall  development 
process  is  to  extend  UML  with  regard  to 
function-driven  systems  engineering,  and 
to  define  a  process  that  enables  a  seam¬ 
less  transfer  of  respective  artifacts  to 
UML-based  software  engineering.  The 
release  of  UML  2.0  [1]  eventually  pro¬ 
vided  the  missing  artifacts  for  function- 
driven  systems  engineering. 

The  following  sections  describe  a 
UML  2.0-based  process  that  systems 
engineers  can  use  to  capture  require¬ 
ments  and  specify  architecture.  The 
approach  uses  model  execution  as  a 
means  for  requirements  verification  and 
validation. 

Process  Overview 

Figure  1  shows  the  integrated  systems 
and  software  engineering  process  by 
means  of  the  classic  V.  The  left  leg  of 
the  V  describes  the  top-down  design 
flow,  while  the  right-hand  side  shows  the 
bottom-up  integration  phases  from  unit 


test  to  the  final  system  acceptance.  Using 
the  notation  of  state-charts,  the  iterative 
characteristic  of  the  process  is  visualized 
by  the  high-level  interrupt  due  to  system 
changes.  Whenever  changes  occur,  the 
process  will  restart  at  the  requirements 
analysis  phase. 

Systems  engineering  is  characterized 
by  a  sequential  top-down  workflow  from 
requirements  analysis  to  system  analysis 
and  system  architectural  design.  A  loop 
back  to  the  requirements  analysis  may 
occur  if,  during  systems  analysis  or  archi¬ 
tectural  design,  functional  issues  require  a 
reexamination  of  the  higher-level  require¬ 
ments.  The  software  engineering  work¬ 
flow  is  characterized  by  the  iterative  and 
incremental  cycles  through  the  software 
analysis  and  design  phase,  the  implemen¬ 
tation  phase,  and  the  different  levels  of 
integration  and  testing. 

It  is  important  to  note  the  creation  and 
reuse  of  requirements-related  test  scenar¬ 
ios  along  the  top-down  design  path.  These 


scenarios  are  also  used  to  assist  the  bot¬ 
tom-up  integration  and  test  phases  and,  in 
the  case  of  system  changes,  regression  test 
cycles. 

Key  objectives  of  the  systems  engi¬ 
neering  process  are  as  follows: 

•  Identification  and  derivation  of 
required  system  functionality. 

•  Identification  of  associated  system 
states  and  modes. 

•  Allocation  of  system  functionality  and 
modes  to  a  physical  architecture. 
Regarding  modeling,  these  key  objec¬ 
tives  imply  a  top-down  approach  on  a  high 
level  of  abstraction.  The  main  emphasis  is 
on  the  identification  and  allocation  of  a 
needed  functionality  (e.g.,  a  target  tracker), 
rather  than  on  the  details  of  its  behavior 
(e.g.,  the  tracking  algorithm). 

Figure  2  depicts  an  overview  of  the 
UML-based  systems  engineering  process. 
For  each  of  the  systems  engineering  phas¬ 
es,  it  shows  the  essential  tasks,  associated 
input,  and  work  products. 


Figure  1:  The  Integrated  Systems  and  Software  Engineering  Process 
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Figure  2:  UMh-Based  Systems  Engineering  Process 


The  process  is  operational  contract- 
driven.  An  operational  contract  specifies 
system  behavior  by  adding  pre-  and  post¬ 
conditions  to  the  description  of  respective 
operations.  Operational  contracts  are  the 
primary  source  of  traceability  to  the  initial 
requirements. 

The  essential  tasks  in  the  requirements 
analysis  phase  are  requirements  capture 
and  the  grouping  of  requirements  into  use 
cases. 

The  main  emphasis  of  the  system 
functional  analysis  phase  is  on  the  trans¬ 
formation  of  the  identified  functional 
requirements  into  a  coherent  description 
of  system  functions  (operational  con¬ 
tracts).  Each  use  case  is  translated  into  a 
respective  black-box  model  and  verified 
and  validated  through  model  execution. 
Incrementally,  these  black-box  use-case 
models  are  merged  to  an  overall  black-box 
system  model. 

The  focus  of  the  subsequent  system 
architectural  design  phase  is  the  allocation 
of  the  verified  and  validated  operational 
contracts  to  a  physical  architecture.  The 
allocation  is  an  iterative  process.  In  collab¬ 
oration  with  domain  experts,  different 
architectural  concepts  and  allocation 

Figure  3:  Case  Study  Use-Case  Diagram 


strategies  may  be  analyzed,  taking  into 
consideration  performance  and  safety 
requirements  that  were  captured  during 
the  requirements  analysis  phase. 

In  the  subsequent  subsystem  architec¬ 
tural  design  phase,  decisions  are  made  on 
which  operational  contracts  within  a  phys¬ 
ical  subsystem  should  be  implemented  in 
hardware  and  which  should  be  imple¬ 
mented  in  software  (hardware/  software 
trade-off  analysis).  The  different  design 
concepts  are  captured  in  the  deployment 
model  and  verified  through  regression 
testing. 

The  deployment  model  defines  the 
system  architecture  baseline  for  the  subse¬ 
quent  hardware  /  software  (HW  /  SW) 
development.  Essential  documents  that 
are  generated  from  the  deployment  model 
are  the  following: 

•  HW/SW  design  specifications. 

•  Logical  interface  control  document 

acD). 

The  outlined  systems  engineering 
process  is  model-based,  using  the  UML 
2.0  as  a  modeling  language.  The  essential 
UML  artifacts  are  the  following: 

•  Use-case  diagram. 

•  Activity  diagram. 

•  State-chart  diagram. 

•  Sequence  diagram. 

•  Structure  diagram. 

The  following  sections  detail  the  work- 
flow  in  the  different  systems  engineering 
phases  with  examples  from  a  case  study. 

Requirements  Analysis 

Requirements  Capture 

The  requirements  analysis  phase  starts 
with  the  analysis  of  the  process  inputs. 
Customer  requirements  are  translated 


into  a  set  of  requirements  that  define 
what  the  system  must  do  (functional 
requirements)  and  how  well  it  must  per¬ 
form  (quality  of  service  requirements). 
The  captured  requirements  are  imported 
into  the  model/requirements  repository. 

Definition  of  Use  Cases 

Once  the  requirements  are  sufficiently 
understood,  they  are  clustered  in  use 
cases.  A  use  case  describes  a  specific  oper¬ 
ational  aspect  of  the  system  (operational 
thread).  It  specifies  the  behavior  as  per¬ 
ceived  by  the  users  and  the  message  flow 
between  the  users  and  the  use  case.  It  does 
not  reveal  or  imply  the  system’s  internal 
structure  (black-box  view). 

A  set  of  use  cases  is  grouped  in  a  use- 
case  diagram.  Use  cases  can  be  structured 
hierarchically.  There  is  no  golden  rule  with 
regard  to  the  number  of  use  cases  needed 
to  describe  a  system.  Experience  shows 
that  for  large  systems,  typically  six  to  24 
use  cases  are  defined  at  the  top  level.  At 
the  lowest  level,  a  use  case  should  be 
described  by  at  least  five  with  a  maximum 
of  25  essential  use-case  scenarios. 

At  this  stage,  emphasis  is  put  on  the 
identification  of  sunny  day  use  cases, 
assuming  an  error/ fail- free  system  behav¬ 
ior.  Exception  scenarios  are  identified  at  a 
later  stage  (=>  system  functional  analysis) 
through  model  execution.  If  more  than 
five  error/fail  scenarios  are  found  for  a 
use  case,  a  separate  exception  use  case  will 
be  defined  and  added  to  the  sunny  day  use 
case  via  the  include  or  extend  relationship. 

Figure  3  shows  the  use-case  diagram 
of  the  case  study.  The  system  is  a  main 
battle  tank.  Two  use  cases  are  studied: 

•  Acquire  target. 

•  Engage  target. 

The  actors  are  commander  and  gunner. 

The  use-case  diagram  is  imported  into 
the  model/requirements  repository.  The 
use  cases  are  then  linked  to  the  system 
requirements  and  checked  for  complete 
coverage. 

System  Functional  Analysis 

In  the  system  functional  analysis  phase, 
each  use  case  is  translated  into  a  model 
and  the  underlying  requirements  then  ver¬ 
ified  and  validated  through  model  execu¬ 
tion.  A  message-driven  approach  (Figure 
4)  is  used.  Characteristics  of  this  approach 
are  the  following: 

•  The  system  structure  is  described  by 
means  of  a  UML  2.0  structure  dia¬ 
gram  using  blocks  as  basic  structure 
elements  and  ports,  and  the  notation 
of  provided/ required  block  interfaces. 

•  Communication  between  blocks  is 
based  on  messages  {service  request^. 
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•  System  functionality  is  captured 
through  operational  contracts  (services), 
e.g.,  operationlOvj  operationdQ  in 
Figure  4. 

•  Functional  decomposition  is  per¬ 
formed  through  decomposition  of 
operational  contracts. 

The  black-box  use  case  analysis  starts 
with  the  definition  of  the  use  case  model 
context  diagram.  The  UML  2.0  artifact 
used  for  this  is  the  structure  diagram. 
Elements  of  this  diagram  are  blocks  rep¬ 
resenting  the  actors  and  the  system. 

Identifying  the  black-box  use-case  sce¬ 
nario  is  the  next  analysis  step.  A  use-case 
scenario  describes  a  specific  path  (func¬ 
tional  flow)  through  a  use  case.  It  details 
the  message  flow  between  the  actors  and 
the  use  case  and  the  resulting  behavior 
(operational  contracts)  of  the  recipient.  In 
the  UML,  a  scenario  is  graphically  repre¬ 
sented  in  a  sequence  diagram.  The  lifelines 
in  the  black-box  sequence  diagram  are  the 
actors  and  the  system  (see  Figure  5). 

Once  a  set  of  essential  scenarios  is 
captured,  the  identified  functional  flow 
information  is  merged  into  a  common  use 
case  description.  The  UML  artifact  used 
for  this  is  the  activity  diagram  (see  Figure 
6).  Each  action  block  in  this  diagram  cor¬ 
responds  to  an  operational  contract  in  a 
sequence  diagram.  The  black-box  activity 
diagram  plays  an  essential  role  in  the 
upcoming  architectural  design  phase. 

Based  on  the  information  captured  in 
the  black-box  sequence  diagrams  and 
black-box  activity  diagram,  the  blocks  of 
the  black-box  use  case  model  next  are 
populated,  and  ports  and  associated  inter¬ 
faces  are  defined.  Figure  7  (see  page  20) 
shows  the  resulting  static  model  of  the  use 
case  Acquire  Target. 

The  next  step  in  black-box  use  case 
analysis  is  the  description  of  system-level, 
state-based  behavior.  The  UML  artifact 
used  for  this  is  the  state-chart  diagram  (see 
Figure  8  on  page  20).  State-charts  are  hier¬ 
archical  state  machines  that  visualize  sys¬ 
tem  states  and  modes  and  their  changes  as 
the  response  to  external  stimuli.  The  use 
case  related  state-based  behavior  is  derived 
from  the  captured  use-case  scenarios. 

At  this  stage,  the  verification  and  vali¬ 
dation  (V&V)  of  the  black-box  use  case 
model  and  the  underlying  requirements 
(i.e.,  operational  contracts)  can  start.  V&V 
is  performed  through  model  execution 
using  the  captured  black-box  use-case  sce¬ 
narios  as  the  basis  for  respective  stimuli.  It 
should  be  noted  that  following  the  previ¬ 
ously  outlined  key  objectives  of  this 
process,  the  focus  is  on  the  analysis  of  the 
generated  sequences  rather  than  on  the 
underlying  functionality. 


So  far,  the  use-case  model  represents 
an  error/ fail  free  (sunny-day)  behavior.  At 
this  stage,  it  may  be  extended  regarding 
possible  exceptions  (rainy-day  behavior). 

The  outlined  steps  are  repeated  for 
each  use  case,  except  that  instead  of  creat¬ 
ing  new  activity  diagrams,  the  initial  black¬ 
box  activity  diagram  incrementally  is 
extended  based  on  the  information  of  the 
new  use-case  scenarios.  The  same  applies 
to  the  system  black-box  state-chart  dia¬ 
gram.  The  subsequent  model  V&V  is  per¬ 
formed  in  two  steps:  First,  the  extended 
black-box  system  model  is  verified/ vali¬ 
dated  through  model  execution  using  the 
black-box  use-case  scenarios  as  the  basis 
for  respective  stimuli.  Then,  the  collabora¬ 
tion  of  the  implemented  use  cases  is  veri¬ 
fied  through  regression  testing. 

At  the  end  of  the  functional  analysis 
phase,  a  black-box  system  model  is  built 
of  verified  and  validated  operational  con¬ 
tracts,  representing  the  underlying  func¬ 
tional  requirements.  The  black-box  system 
model  is  imported  into  the  model/ 
requirements  repository  and  the  opera¬ 
tional  contracts  are  linked  to  the  high-level 
system  requirements.  The  black-box  use- 
case  scenarios  are  imported  into  the  test 
data  repository  for  reuse  in  the  subse¬ 
quent  architectural  design  phases. 

Architectural  Design 

System  Architectural  Design 

Focus  of  the  system  architectural  design 
phase  is  the  allocation  of  the  verified 
and  validated  operational  contracts  to  a 
physical  architecture.  The  allocation  is  an 
iterative  process  and  is  performed  in  col¬ 
laboration  with  domain  experts. 
Different  architectural  concepts  and 
allocation  strategies  may  be  analyzed, 
taking  into  consideration  performance 
and  safety  requirements  that  were  cap- 


Figure  4:  Message-Driven  Modeling  Approach 
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Figure  7:  Static  Black-Box  System  Model  (Use  Case  Mcquire  Target) 


tured  during  the  requirements  analysis 
phase. 

System  architectural  design  starts  with 
the  definition  of  the  physical  subsystems. 
The  UML  2.0  artifact  used  for  this  is  the 


structure  diagram.  Constituents  of  this 
model  are  the  actor  blocks  and  the  system 
block.  Parts  of  the  system  block  are  the 
physical  subsystems  of  the  chosen  archi¬ 
tecture.  In  the  case  study,  the  system 


Figure  ^ 
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design  consists  of  six  physical  subsystems 
(LRU  =  line  replaceable  unit,  see  Figure 
9A). 

Next,  the  previously  identified  black¬ 
box  operational  contracts  are  allocated  to 
the  physical  subsystems  using  an  activity 
diagram  (white-box  activity  diagram). 
Essentially,  this  activity  diagram  is  a  copy 
of  the  black-box  activity  diagram.  The 
only  difference  is  that  the  system  now  is 
partitioned  into  swim  lanes,  each  repre¬ 
senting  a  physical  subsystem.  Based  on  the 
chosen  design  concept,  the  system  opera¬ 
tional  contracts  are  moved  to  respective 
subsystem  swim  lanes.  An  essential  pre¬ 
condition  for  this  allocation  is  that  the  ini¬ 
tial  links  (functional  flow)  between  the 
operational  contracts  are  maintained. 

The  white-box  activity  diagram  is 
complemented  by  the  definition  of  white- 
box  sequence  diagrams.  White-box 
sequence  diagrams  are  decompositions  of 
the  previously  captured  black-box 
sequence  diagrams  and  are  utilized  to 
identify  the  interfaces  of  the  physical  sub¬ 
systems.  In  white-box  sequence  diagrams, 
the  system  lifeline  is  split  into  a  set  of  sub¬ 
system  lifelines.  Based  on  the  allocation 
defined  in  the  white-box  activity  diagram, 
the  subsystem  operational  contracts  are 
placed  on  respective  subsystem  lifelines. 
To  maintain  the  initial  functional  flow, 
service  requests  from  one  physical  subsys¬ 
tem  to  the  other  may  need  to  be  generat¬ 
ed.  They  define  the  interfaces  between  the 
subsystems. 

In  the  example  shown  in  Figure  1 0,  the 
implementation  concept  was  that  LRUl 
was  considered  the  commander’s  input/ 
output  device.  Most  of  the  identified 
functionality  had  to  be  implemented  in 
LRUS.  The  Commander’s  Independent 
Thermal  Viewer  control  had  to  be  in 
LRU6.  In  this  scenario,  LRU4  served  as  a 
gateway  between  LRUl  and  LRUS.  By 
mapping  the  use  case  scenario  to  the  phys¬ 
ical  architecture,  the  links  and  the  associ¬ 
ated  ports  and  interfaces  are  defined  for 
each  involved  physical  subsystem.  For 
each  physical  subsystem,  the  associated 
state-based  behavior  is  captured  in  a  state- 
chart  diagram.  These  state-chart  diagrams 
will  extend  incrementally  with  each 
mapped  use-case  scenario. 

The  outlined  process  is  performed 
iteratively  for  all  black-box  scenarios. 
Figure  9 A  shows  the  final  result.  Figure 
9B  depicts  for  the  chosen  architectural 
design  the  resulting  physical  subsystem 
interfaces  by  means  of  an  N-squared  (N^) 
chart.  An  chart  is  structured  by  locat¬ 
ing  the  nodes  of  communication  on  the 
diagonal,  resulting  in  an  NxN  matrix  for  a 
set  of  N  nodes.  For  a  given  node,  all  out- 
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puts  (UML  2.0  required  interface^  are  locat¬ 
ed  in  a  row  of  that  node  and  inputs  (UML 
2.0  provided  interfaces)  are  in  the  column  of 
that  node. 

The  correctness  and  completeness  of 
the  system  architecture  model  is  checked 
through  model  execution.  Once  the 
model  functionality  is  verified,  the  archi¬ 
tectural  design  can  be  analyzed  with 
regard  to  the  performance  and  safety 
requirements.  The  analysis  typically 
includes  failure  modes  effects  analysis  and 
mission  criticality  analysis. 

Subsystem  Architectural 
Design 

This  phase  focuses  on  the  implementation 
of  the  allocated  operational  contracts. 
Decisions  are  made  on  which  operational 
contracts  in  a  physical  subsystem  should 
be  implemented  in  hardware  (mechani¬ 
cal/application-specific  integrated  circuit) 
and  which  should  be  implemented  in  soft¬ 
ware.  For  operational  contracts  that  span 
more  than  one  domain,  further  analysis 
will  be  needed.  Subsystem  domain  experts 
may  participate  in  this  analysis. 

Once  the  HW/SW  design  decisions 
are  made,  the  workflow  is  similar  to  the 
one  outlined  in  the  system  architectural 
design  phase.  In  each  white-box  use-case 
scenario,  the  physical  subsystem  lifelines 
are  split  into  HW  and/or  SW  lifelines, 
each  representing  a  subsystem  compo¬ 
nent.  Based  on  the  chosen  HW/SW 
design  concept,  operational  contracts  then 
are  placed  on  respective  subsystem  com¬ 
ponent  lifelines,  and  the  associated  func¬ 
tional  flow  between  subsystems  and  sub¬ 
system  components  established  through 
respective  service  requests  (see  Figure  11 
on  page  22).  Thus,  subsystem  component 
ports  and  interfaces  are  defined.  For  each 
physical  subsystem  component,  the  asso¬ 
ciated  state-based  behavior  is  captured  in  a 
state-chart  diagram.  These  state-chart  dia¬ 
grams  will  extend  incrementally  with  each 
white-box  use-case  scenario. 

The  outlined  process  is  performed 
iteratively  for  all  white-box  scenarios. 
The  final  deployment  architecture  is  ver¬ 
ified  through  regression  testing. 

At  the  end  of  the  system  architectur¬ 
al  design  phase,  the  deployment  model  is 
imported  into  the  model/requirements 
repository,  and  the  HW/SW  assigned 
operational  contracts  are  linked  to  the 
original  requirements.  For  each  physical 
subsystem  the  following  documents  are 
generated  from  the  deployment  model  as 
handoffs  to  the  subsequent  hardware 
and  software  design: 

•  HW/SW  design  specification. 


•  Logical  interface  control  document 
(N^  chart). 

•  Subsystem/subsystem  component 
test  vectors  derived  from  the  system- 
level  use-case  scenarios. 

Conclusion 

For  a  long  time,  the  UML  was  consid¬ 
ered  a  modeling  language  suitable  only 
for  software  developers  that  follow  the 
object-oriented  paradigm.  This  article 
demonstrates  that  with  the  release  of 
UML  2.0  —  specifically  with  the  intro¬ 
duction  of  (composite)  structure  dia¬ 
grams  -  the  UML  could  also  be  applied 
to  function- driven  systems  engineering. 


Based  on  this  common,  paradigm-inde¬ 
pendent  language  for  both  systems  engi¬ 
neers  and  software  engineers,  an  inte¬ 
grated  systems/software  development 
process  could  be  defined,  allowing  a 
seamless  transition  between  the  two 
domains.  Still,  the  UML  needs  some 
extensions  to  cover  the  needs  of  systems 
engineers  completely  (e.g.,  time-continu¬ 
ous  communication).  For  this  purpose, 
the  object  management  group  formed 
the  Systems  Modeling  Language  (SysML) 
consortium  [2].  The  first  release  of  the 
SysML  specification  will  be  in  the  fourth 
quarter  2005. ♦ 


Figure  10:  White-Box  Scenario  UC1WB21  (Decomposed  Black-Box  Scenario  of  Figure  5) 


ac_Cmdr 

- - 


// 

Cmdr  tracks  in  mode  %  1.  reqCaIcCmdrLosCmdO  s.i 
CITV-GLOS  %  ^ 


'/a 


Step1>9  repeated  until 
evDIsengageCmdrPalms 


I 


2.  reqCalcCmdrLosCmdQ 


3,  reqCalcCmdrLosCmdQ 


4.  caIcCmdrLosCmdd  j 
reqMoveCitvO  d 


□ 

(sTreqMo 


I 

1^7.  reqAlignGp32CitvO  i 
I  8.  aliqnGL2atv(| 

Ps.  aligiiGun2Gps(|  I 

I 

I  I 

I  I 


13 


moveCitvO 


November  2005 


www.stsc.hill.af.mil  2 1 


Design 


CR0SSTALK4> 

Ttia  journal  of  Dafiiniv  Sofcwrara  inihnaarln| 

Get  Your  Free  Subscription 
Fill  out  and  send  us  this  form. 


309  SMXG/MXDB 
6022  Fir  Ave 
Bldg  1238 

Hill  AFB,  UT  84056-5820 
Fax:  (801)  777-8069  DSN:  777-8069 
Phone:  (801)  775-5555  DSN:  775-5555 

Or  request  online  at  www.stsc.hill.af.nnil 


Name:. 


rn 


in 


j  rmC*]CClTMM.fttClTHH>  ^ 

I 


1 


r~ 


n  ibmCIwO 

I  LP 

^  WHAIISrtG^iUffl  [ 

rtiianc 


rails, 

P 


Rank/Grade:_ 
Position/Title: 
Organization:_ 
Address: _ 


Base/City:. 


Figure  1 1 :  Subsystem  Architectural  Design 


State: _ Zip:. 

Phone:  ( _ ) _ 

Fax:  ( _ ) _ 

E-mail: _ 


References 

1.  Object  Management  Group.  Unified 
Modeling  Language.  ‘'UML  2.0 
Specification”  17  Aug.  2005  <www. 
uml.org/#UML2.0>. 

2.  SysML  Forum.  ‘'SysML  Specification 
Vers.  0.9  Draft”  10  Jan.  2005.  17  Aug. 
2005  <www.sysml.org/ artifacts.htm>. 


About  the  Author 

Hans-Peter  Hoffmann, 

chief  methodologist  for 

tured  systems  design  automation  tool 
vendor.  Focusing  on  methodology  con¬ 
sulting,  Hoffman  works  as  an  interna¬ 
tional  consultant  for  model-based  sys¬ 
tem  development.  He  has  25  years  expe¬ 
rience  in  the  design  and  development  of 
complex  systems  in  the  aerospace/ 
defense  and  automotive  industries. 
Hoffmann  co-developed  the  I-Logix 
Integrated  Systems/Software  Develop¬ 
ment  Process  HARMONY,  which  com¬ 
bines  Unified  Modeling  Language 
(UML)  / Systems  Modeling  Language- 
based  systems  engineering  and  UML- 
based  software  engineering.  Previously 
as  director  of  the  simulation  depart¬ 
ment  of  the  Missile  Division  at  Messer- 
schmitt-Bolkow-Blohm  Germany,  (now 
European  Aeronautic  Defense  and 
Space  Company  N.V.),  he  developed  a 
methodology  for  modeling  and  analysis 
of  flight  control  systems. 

I-Logix  Inc. 

3  Riverside  DR 
Andover,  MA  01810 
Phone:  (978)  645-3022 
Fax:  (978)  682-5995 
E-mail:  peterh(^ilogix.com 


Check  Box(es)  To  Request  Back  Issues: 
July2004  n  Top  5  Projects 
Aug2004  □  Systems  Approach 
Sept2004  n  Software  Edge 
Oct2004  □  Project  Management 
Nov2004  □  Software  Toolbox 
Dec2004  □  Reuse 
Jan2005  n  Open  Source  SW 
Feb2005  Q  Risk  Management 
Mar2005  Q  Team  Software  Process 
Apr2005  n  Cost  Estimation 
May2005  n  Capabilities 
June2005  n  Reality  Computing 
JULY2005  n  CONFIG.  MgT.  AND  TEST 
Aug2005  n  Sys:  fieldg.  Capabilities 
Sept2005  n  Top  5  Projects 
Oct2005  n  Software  Security 

To  Request  Back  Issues  on  Topics  Not 
Listed  Above,  Please  Contact  <stsc. 

CUSTOMERSERVICE@HILL.AF.MIL>. 


Web  Sites 


International  Association 
of  Software  Architects 

WWW,  ias  architects .  org 
The  International  Association  of 
Software  Architects  (lASA)  is  a  nonprofit 
organization  dedicated  to  the  advance¬ 
ment  and  sharing  of  issues  related  to  soft¬ 
ware  architecture  in  the  enterprise,  prod¬ 
uct,  education,  and  government  sectors. 
lASA  functions  as  an  umbrella  organiza¬ 
tion  to  chapters  spread  throughout  the 
world,  and  as  a  driving  force  for  research 
and  standards  that  advance  the  under¬ 
standing  of  software  architecture.  lASA 
helps  sustain  city  chapters  by  forming 
software  architecture  user  groups  and  by 
fostering  the  sharing  of  ideas  and  infor¬ 


mation  between  these  city  groups  and 
industry  leaders. 

International  Enterprise 
Architecture  Center 

www.ieac.org 

The  International  Enterprise  Architec¬ 
ture  Center  (lEAC)  is  a  global,  inde¬ 
pendent,  nonprofit  professional  member¬ 
ship  organization  dedicated  to  the  dis¬ 
semination  of  knowledge  about  enter¬ 
prise  architectures,  management,  and  the 
marketplace  to  help  members  strengthen 
their  performance  and  better  serve  socie¬ 
ty.  The  lEAC  assists  in  the  development 
of  enterprise  architecture  frameworks, 
methods  and  disciplines  across  all  enter¬ 
prise  environments. 


22  CrossTalk  The  Journal  of  Defense  Software  Engineering 


November  2005 


Software  Engineering  Technology 


Security  in  a  COTS-Based  Software  System 


Arlene  F.  Minkiewicz 
PRICE  Systems 

Planning  and  budgeting  for  the  development  of  a  software  system  composed  primarily  of  commercial  off-the-shelf  (COTS) 
components  presents  unique  challenges  to  those  with  project  and  process  responsibilities.  These  challenges  are  further  intensi¬ 
fied  when  security  issues  are  present  such  as  security  requirements  in  the  system  being  developed,  security  constraints  applied 
to  the  development  team,  or  both.  Because  these  security  issues  may  impact  the  functional  si^e  of  the  software  being  developed, 
the  productivity  of  the  development  team,  and  the  ability  of  the  team  to  communicate,  they  are  important  considerations  when 
estimating  cost  and  effort  for  any  software  project.  They  have  additional  effects  when  the  system  is  COTS -based.  In  A.ugusfs 
Crosstalk^  work  by  this  author  presented  a  methodolo^  for  approaching  COTS -based  software  projects  [1].  This  arti¬ 
cle  extends  that  methodology  to  consider  the  impacts  that  security  requirements  or  constraints  may  impose  on  each  of  the  activ¬ 
ities  in  the  process.  It  presents  an  overview  of  the  causes  of  security  vulnerabilities  in  software  and  an  understanding  of  how 
to  assess  what  impact  security  constraints  will  have  on  your  COTS -based  software  projects. 


The  developers  of  software  systems  are 
relying  on  incorporating  commercial 
off-the-shelf  (COTS)  software  compo¬ 
nents  to  decrease  cost  and  time  to  market 
for  delivery  of  new  software  systems. 
Increasingly,  the  procurers  of  these  soft¬ 
ware  systems  are  driving  this  decision  to 
consider  COTS  solutions  for  significant 
functionality.  This  emergence  of  COTS 
solutions  as  viable  and  desirable  has 
occurred  over  time  and  has  not  been  with¬ 
out  trials  on  both  sides.  It  has  taken  time 
for  software  developers  and  their  cus¬ 
tomers  to  begin  to  understand  where 
COTS  solutions  will  save  money  and 
where  they  will  not.  Great  strides  have 
been  made  in  this  area,  but  there  is  still 
much  to  learn. 

As  this  COTS  revolution  unfolds, 
another  issue  emerges  that  impacts  the 
entire  software  industry  and  has  particular 
ramifications  to  those  developing  COTS- 
based  systems.  This  issue  is  the  increased 
need  for  security  in  software  systems  driv¬ 
en  by  rapidly  growing  networking  capabil¬ 
ities  introduced  by  leaps  in  networking 
technology  and  the  corresponding  leaps  in 
dependence  on  this  technology.  Accord¬ 
ing  to  the  National  Strategy  to  Secure 
Cyberspace: 

Identified  computer  security  vul¬ 
nerabilities  —  faults  in  software  and 
hardware  that  could  permit  unau¬ 
thorized  network  access  or  allow 
an  attacker  to  cause  network  dam¬ 
age  —  increased  significantly  from 
2000  to  2002,  with  the  number  of 
vulnerabilities  going  from  1,090  to 
4,129.  [2] 

The  Computer  Emergency  Response 
Team  Coordination  Center  at  Carnegie 


Mellon  University,  which  tracks  incidents  of 
malicious  software  intrusions,  reports  a 
2,099  percent  increase  in  incidents  from 
1998  to  2002.  These  incidents  range  from 
security  breaches  impacting  a  single  site  to 
those  impacting  hundreds  of  sites  [3]. 
These  security  breaches  cost  US.  industry 
and  government  billions  of  dollars. 

At  the  same  time  that  purchasers  of 
software  systems  are  driving  solution 
providers  toward  possible  cost  savings 
with  a  well-implemented  COTS-based 
solution,  they  are  putting  additional 
demands  on  the  software  developers  that 
these  solutions  meet  specific  software 
security  criteria.  These  criteria  are  general¬ 
ly  based  on  Evaluation  Assurance  Levels 
(EALs)  as  specified  in  the  Common 
Criteria  (CC)  for  Information  Technology 
Security  Evaluation  [4]  or  some  analog  to 
these  criteria.  The  CC  sets  a  standard  for 
assigning  levels  of  security  compliance  of 
software.  This  additional  requirement  for 
secure  software  could  clearly  throw  new 
and  unexpected  complications  into  the 
slowly  emerging  sense  of  what  drives  the 
costs  of  COTS-based  software  projects. 

This  article  addresses  the  software 
security  issue  in  general  and  then  in  the 
context  of  developing  COTS-based  sys¬ 
tems.  It  begins  with  an  outline  of  the 
author’s  methodology  for  this  research, 
then  describes  and  bounds  the  problem 
being  addressed.  Next,  the  issues  sur¬ 
rounding  software  security  are  addressed. 
The  author  then  outlines  the  six  steps  to  a 
successful  COTS  implementation  and 
addresses  how  these  steps  are  impacted  by 
security  requirements. 

Solution  Methodology 

The  first  step  in  any  operations  research 
project  is  to  identify  the  problem  being 


solved.  The  problem  we  are  attempting  to 
solve  is  that  of  identifying  how  security 
constraints  impact  the  activities  involved 
in  delivering  a  COTS-based  software  sys¬ 
tem  and  how  these  impacts  affect  project 
costs.  This  was  accomplished  using  litera¬ 
ture  reviews,  expert  knowledge,  and  inter¬ 
views  with  practitioners  to  supplement  the 
cost  data  available. 

Once  the  problem  is  identified,  the 
next  step  in  constructing  a  parametric 
cost-estimating  solution  is  to  study  and 
understand  the  subject  process,  and  from 
this  construct  a  mathematical  model. 
Research  led  to  the  development  of  a 
mathematical  model  based  on  assump¬ 
tions  of  productivity  standards  for  each 
activity  in  the  process,  and  adjustments  of 
these  standard  values  to  accommodate  for 
the  additional  rigor  and  processes  associ¬ 
ated  with  elevated  security  requirements. 

This  mathematical  model  was  then 
exercised  by  software  developers  and  proj¬ 
ect  mangers  to  determine  how  it  fared 
when  applied  to  real-life  situations.  Once 
satisfied  that  the  model  was  useful  for 
practitioners,  data  from  various  datasets 
containing  both  commercial  and  aero¬ 
space  data  was  applied  to  determine  where 
it  worked  well  and  where  further  work  was 
required. 

Bounding  the  Problem 

COTS-based  software  solutions  can  be  a 
cost  effective  method  for  successfully 
delivering  software  systems  if  these  proj¬ 
ects  are  planned  with  a  proper  under¬ 
standing  of  the  activities  associated  with 
the  implementation  and  on-going  suste¬ 
nance  of  COTS-based  software  systems. 
These  activities  and  their  cost  drivers  have 
been  well  defined  in  [5].  Adding  security 
constraints  to  a  COTS-based  software  sys- 
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tern  will  affect  the  execution  of  some  of 
these  activities  and,  correspondingly, 
change  how  these  activity’s  costs  should 
be  evaluated. 

In  bounding  the  problem,  it  is  impor¬ 
tant  to  understand  what  definition  of 
COTS  is  being  applied  and  how  security 
constraints  are  measured.  To  have  a  mean¬ 
ingful  discussion  on  the  costs  of  COTS 
software,  it  is  important  to  start  with  a 
clear  understanding  of  what  is  and  is  not 
included  when  we  discuss  COTS  software. 
For  this  article,  we  started  with  the  defini¬ 
tion  from  the  University  of  Southern 
California’s  Center  for  Software  Excel¬ 
lence  study  that  led  to  the  Constructive 
COTS  (CoCOTS)  model  [6].  The  defini¬ 
tion  of  a  COTS  software  product  follows: 

•  Commercially  available  software  prod¬ 
uct  —  sold,  leased,  or  licensed. 

•  Source  code  unavailable  but  documen¬ 
tation  provided. 

•  Periodic  releases  with  new  features, 
upgrades  for  technology,  etc. 

We  found  this  definition  too  limiting 
for  several  reasons.  It  is  not  consistent 
with  many  of  our  observations  of  actual 
COTS  software  integration  efforts. 
Customization  appears  to  be  quite  com¬ 
mon,  particularly  with  embedded  COTS 
software.  In  creating  a  general-purpose 
solution,  it  seemed  important  that  we  not 
overlook  the  issue  of  customization.  For 
this  reason  the  definition  was  altered  to 
include  off-the-shelf  software  with  source 
code  available. 

We  have  used  the  CC  as  the  basis  for 
evaluating  security  requirements.  It  was 
developed  to  provide  a  standard  for  secu¬ 
rity  criteria  and  evaluation  processes  of 
that  criteria.  The  CC  contains  seven  hier¬ 
archical  sets  of  assurance  requirements 
called  EAL’s  and  named  EALl  through 
EAL7,  with  EALl  representing  the  least 
amount  of  security  and  EAL7  represent¬ 
ing  the  most  security.  Increasing  degrees 
of  documentation,  design  rigor,  formal 
processes,  etc.  are  required  as  you  move 
from  EALl  to  EAL7. 

Software  security  issues  can  be 
grouped  into  three  categories  [7]: 

•  Development  for  Security.  The 
effect  of  security  constraints  on  the 
development  of  software. 

•  Operational  Security.  The  effect  of 
security  policies  and  processes  on  the 
development  environment. 

•  Physical  Security.  The  effect  of 
developing  software  in  a  secure  envi¬ 
ronment. 

The  research  in  this  article  only  covers 
the  first  two  of  these  categories.  Physical 
security  is  left  as  a  future  research  chal¬ 
lenge. 


Software  Security 

In  its  report  issued  March  2004,  the 
Software  Process  Subgroup  of  the  Task 
Force  on  Security  across  the  software 
development  life  cycle  defines  the  goals  of 
software  security: 

The  primary  goals  of  software 
security  are  the  preservation  of  the 
confidentiality,  integrity,  and  avail¬ 
ability  of  the  information  assets 
and  resources  that  the  software 
creates,  stores,  processes,  or  trans¬ 
mits,  including  the  executing  pro¬ 
grams  themselves.  [3] 

In  other  words,  users  of  secure  software 
have  a  reasonable  expectation  that  their 
data  is  protected  from  unauthorized 
access  or  modification  and  that  their  data 
and  applications  remain  available  and  sta¬ 
ble.  Clearly  some  applications  have  a  need 
for  a  much  higher  degree  of  assurance 
than  others.  Software  designed  for  stand¬ 
alone  desktop  use  is  much  less  likely  to  be 


^^Despite  the  advances 
that  the  software 
industry  has  made  in 
development  practices 
and  processes,  the  buffer 
overflow  continues  to  be 
the  most  frequently  cited 
security  vulnerability 

subject  to  threats  than  multi-user  software 
intended  for  use  across  a  network. 
Software  that  is  shipping  confidential 
client  information  or  government  secrets 
requires  more  security  than  the  instant 
messaging  software  that  is  the  backbone 
of  teenage  culture. 

As  increasing  security  constraints  will 
increase  the  cost  of  developing  and  main¬ 
taining  any  software  system,  it  becomes  an 
important  part  of  the  software  acquisition 
process  to  understand  the  required  level  of 
assurance  based  on  the  functionality  the 
software  is  intended  to  perform  and  the  end 
users  who  will  consume  that  functionality. 

Software  security  requirements  present 
themselves  in  two  forms.  The  first  are 
those  requirements  that  impose  additional 
functional  requirements  for  features 
specifically  related  to  security.  Examples 


of  these  are  encryption  algorithms,  pass¬ 
word  protection  requirements,  or  remote 
access  security  procedures.  The  second 
form  of  security  requirements  relate  to 
the  additional  levels  of  qualification  and 
testing  required  to  ensure  that  the  soft¬ 
ware  does  not  allow  security  breaches  into 
the  system  on  which  it  operates  or  the 
data  it  maintains.  These  requirements 
involve  ensuring  there  are  no  back  doors, 
buffer  overflows,  or  defects  that  allow 
entry  to  hackers.  They  also  require  that 
patch  releases  be  handled  in  such  a  way 
that  the  wise  hacker  cannot  use  them  as 
road  maps  to  the  weaknesses  in  the  soft¬ 
ware  system. 

The  functional  requirements  related  to 
security  impact  cost  primarily  through 
increased  functional  size  of  the  applica¬ 
tion.  When  the  software  is  being  devel¬ 
oped  in-house,  this  additional  size  drives 
design,  code,  and  test  activities  for  these 
requirements.  When  the  software  is 
COTS,  this  additional  size  drives  integra¬ 
tion  and  test  activities. 

Before  a  conversation  can  take  place 
about  the  cost  impacts  of  compliance  to 
specific  security  assurance  levels,  it  is 
important  to  understand  the  various 
COTS  selection  strategies  that  might 
apply.  The  selection  strategy  applied  deter¬ 
mines  where  in  the  COTS  implementation 
process  the  costs  will  be  incurred  and 
what  the  extent  of  those  effects  might  be. 
There  are  basically  three  choices  an  inte¬ 
grator  has  when  selecting  COTS  compo¬ 
nents  for  a  software  system: 

•  Buy  and  wrap. 

•  Buy  only  pre-certified  components. 

•  Buy  components  and  certify  internally. 

The  buy-and-wrap  option  indicates  that 

the  integrator  intends  to  purchase  the 
COTS  components  that  best  meet  the 
functional  requirements  for  the  software. 
The  integrator  will  then  develop  a  glue 
code  wrapper  that  operates  around  this 
component,  isolating  it  so  that  any  securi¬ 
ty  threats  inherent  in  the  COTS  compo¬ 
nent  cannot  be  reached  through  the  result¬ 
ant  applications. 

An  integrator  who  opts  to  buy  only  pre¬ 
certified  components  intends  to  limit  evalua¬ 
tions  to  COTS  components  from  vendors 
that  have  certified  their  components  to 
the  required  level  of  compliance.  This 
reduces  the  integrator’s  development  and 
integration  effort,  but  limits  the  selections 
and  is  likely  to  increase  the  purchase  and 
maintenance  costs  of  the  COTS  compo¬ 
nents.  It  may  also  lead  to  the  necessity  to 
develop  more  in-house  functionality  if 
properly  certified  components  are  unavail¬ 
able  for  some  functional  requirements. 

The  option  to  buy  components  and 
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certify  internally  seems  the  least  desirable 
of  all  options.  When  this  path  is  taken, 
the  integrator  purchases  the  components 
that  best  meet  their  requirements  and 
then  has  these  components  certified  to 
the  required  level  of  compliance.  The 
integrator  can  select  components  that 
meet  functional  requirements,  but  then 
must  bear  the  burden  and  expense  of  the 
certification  process.  If  the  certification 
fails,  the  integrator  must  then  restart  the 
evaluation  and  selection  process  to  iden¬ 
tify  other  potential  solutions  and  must 
contend  with  the  fact  that  they  have  pur¬ 
chased  software  that  has  no  value. 

Security  breaches  in  software  are 
caused  by  defective  specification,  design, 
and  implementation  [3].  Lack  of  quality 
in  software  creates  openings  through 
which  threats  can  be  realized.  Despite  the 
advances  that  the  software  industry  has 
made  in  development  practices  and 
processes,  the  buffer  overflow  continues 
to  be  the  most  frequently  cited  security 
vulnerability  according  to  a  paper  pub¬ 
lished  by  the  Oregon  Graduate  Institute 
of  Science  and  Technology  [8].  Other 
defects  that  lead  to  security  breaches 
include  format  bugs,  resource  leaks,  hard¬ 
coded  path  names,  and  malformed 
inputs.  Additionally,  sloppy  implementa¬ 
tion  of  encryption  algorithms,  password 
transmission  routines,  and  graceful  fail¬ 
ures  lead  to  security  breaches. 

Clearly  software  that  has  been  devel¬ 
oped  and  integrated  by  organizations  that 
have  invested  in  putting  proven  software 
engineering  practices  and  processes  in 
place  is  going  to  reach  security  assurance 
level  compliance  with  less  cost  (and  less 
drama)  than  software  developed  in  a 
more  ad-hoc  fashion.  The  institutional¬ 
ization  of  good  software  development 
processes  is  an  important  factor  to  con¬ 
sider  when  planning  a  project  with  secu¬ 
rity  constraints. 

Another  commonly  cited  cause  for 
vulnerabilities  in  software  is  the  training 
and  expertise  of  the  developers  and  inte¬ 
grators  of  software  systems.  The  success¬ 
ful  implementation  of  secure  software 
systems  requires  that  security  and  quality 
be  considerations  from  day  one.  The 
skills  required  to  do  this  are  not  innate 
and  have  not  traditionally  been  stressed 
as  part  of  a  typical  computer  science  or 
software  engineering  curriculum. 
Although  this  condition  is  improving 
with  respect  to  good  software  develop¬ 
ment  practices,  those  skills  related  specif¬ 
ically  to  security  concerns  continue  to  be 
overlooked  in  many  instances.  The  cost 
impact  of  fixing  a  software  system  not 
designed  and  implemented  to  be  a  secure. 


defect-free  system  is  substantially  higher 
than  the  cost  of  developing  it  from  the 
ground  up. 

Six  Steps  to  a  Successful 
COTS  Implementation 

To  understand  the  cost  impacts  of  secu¬ 
rity  constraints  on  the  development  of  a 
COTS-based  system,  it  is  important  to 
first  understand  the  activities  that  occur 
during  any  successful  COTS-based  soft¬ 
ware  project.  These  activities  are  briefly 
outlined  below.  Also,  [1]  and  [4]  present 
more  detailed  descriptions  of  this 
process.  Research  has  indicated  the 
essential  activities  that  must  take  place  to 
ensure  successful  COTS-based  projects 
are  the  following: 

•  Analyze  software  requirements. 

•  Evaluate  and  select  COTS  solution (s). 

•  Negotiate  terms  with  vendors. 

•  Implement  the  COTS-based  solution. 

•  Maintain  license,  subscription,  and 
royalty  fees. 

•  Maintain  and  upgrade  the  COTS- 
based  solution. 

Analyze  Software  Requirements 

Software  requirements  analysis  should 
occur  regardless  of  whether  the  decision 
is  made  to  build,  buy,  or  borrow.  A  prop¬ 
er  understanding  of  system  requirements 
that  are  to  be  satisfied  by  software  is 
essential  to  a  successful  software  project. 
It  is  during  the  software  requirements 
analysis  activity  that  decisions  can  be 
made  as  to  which  requirements  can  be 
satisfied  with  off-the-shelf  components. 

Evaluate  and  Select  COTS 
Solution(5) 

Once  a  decision  to  pursue  a  COTS  alter¬ 
native  is  made,  the  first  step  is  to  deter¬ 
mine  the  availability  of  COTS  solutions 
that  have  the  potential  to  provide  needed 
functionality  and  evaluate  these  solutions. 
The  evaluation  needs  to  be  focused  on 
more  than  just  product  characteristics 
such  as  functionality,  architecture,  and 
technology,  but  also  on  vendor  character¬ 
istics  such  as  maturity,  stability,  and  abili¬ 
ty  to  provide  adequate  support,  training, 
and  documentation. 

Negotiate  Terms  With  COTS  Vendors 

Certainly  it  is  important  to  negotiate  the 
best  deal  possible  when  working  with  one 
or  more  vendors  to  craft  a  solution. 
Vendors  are  much  more  likely  to  address 
customer  concerns  with  missing  or 
incomplete  functionality  as  well  as  bugs 
in  the  software  before  they  sign  on  the 
dotted  line. 


Implement  the  COTS-Based  Solution 

Once  an  analysis,  evaluation,  and  selection 
of  a  COTS-based  solution  is  complete, 
implementation  can  commence.  Imple¬ 
mentation  includes  the  tailoring  of  the 
COTS  components;  modifications  to 
COTS  software  (if  this  is  possible  and 
desirable);  design,  code,  and  test  of  any 
glue  code  required;  and  higher  level  inte¬ 
grations  of  COTS  components  with  other 
components. 

Maintain  License,  Subscription,  and 
Royalty  Fees 

License  or  maintenance  fees  need  to  be 
paid  to  ensure  updates  and  upgrades  as 
well  as  continuing  support  of  the  COTS 
components. 

Maintain  and  Upgrade  the 
COTS-Based  Solution 

Once  the  software  is  deployed,  there  are 
several  ongoing  activities  required  to  keep 
it  operational  and  keep  end  users  happy. 
These  include  the  ongoing  evaluation  of 
upgrades  from  the  vendor,  inclusion  of 
those  upgrades  when  desirable,  bug  fixes 
in  glue  code  or  to  compensate  for  errors 
in  the  COTS  components  the  vendor  will 
not  fix,  and  higher  level  integration  as 
upgrades  and  bug  fixes  are  deployed. 

Security  Implications  for  the 
Six  Steps 

The  previous  section  outlined  the  activi¬ 
ties  that  should  take  place,  and  thus 
should  be  part  of  the  plan,  for  the  imple¬ 
mentation  of  any  COTS-based  system. 
This  section  looks  at  the  additional  factors 
that  must  be  considered  when  the  COTS 
implementation  includes  requirements  to 
comply  with  security  constraints,  and 
highlights  how  those  factors  will  impact 
activity  costs  as  compared  to  the  costs  of 
those  same  activities  with  nominal  securi¬ 
ty  constraints. 

Analyze  Software  Requirements 

During  the  Requirements  Analysis  activity, 
functional  security  requirements  need  to 
be  analyzed,  along  with  the  non- function¬ 
al  ones.  From  a  cost  and  planning  per¬ 
spective,  these  additional  requirements 
should  be  modeled  as  an  additional  func¬ 
tional  size  that  needs  to  be  either  devel¬ 
oped  or  purchased  and  integrated. 
Functional  size  can  be  any  measure  of 
software  size  that  relates  to  the  amount  of 
user  functionality  that  is  being  delivered 
such  as  function  points  or  feature  points. 
An  additional  cost  consideration  is  the 
amount  of  skill  and  expertise  the  integra¬ 
tion  team  has  with  implementing  secure 
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software  systems.  It  is  during  the  require¬ 
ments  analysis  phase  that  the  COTS  selec¬ 
tion  strategy  is  likely  to  be  determined. 

Evaluate  and  Select  COTS 
Solution(s) 

The  COTS  selection  strategy  plays  a  big 
part  in  determining  the  impact  of  security 
constraints  on  this  activity.  If  the  strategy 
is  to  buy  and  wrap  COTS  components, 
then  the  evaluation  and  selection  activity 
effort  should  focus  entirely  on  the  func¬ 
tional  requirements  for  which  COTS  com¬ 
ponents  are  being  considered,  with  little 
attention  paid  to  the  security  requirements 
since  this  will  be  taken  care  of  externally 
to  the  COTS  components.  The  cost 
impacts  of  this  activity  would  be  a  func¬ 
tion  of  the  total  number  of  COTS  solu¬ 
tions  available  for  consideration,  along 
with  the  number  expected  to  be  selected 
for  more  detailed  consideration.  The  deci¬ 
sion  to  build  a  wrapper  also  impacts  the 
cost  of  glue  code  development  (described 
below)  as  the  need  for  wrapper  code 
increases  the  amount  and  complexity  of 
glue  code  that  must  be  developed. 

If  the  strategy  is  to  buy  pre-certified 
components,  you  would  expect  this  to 
have  substantial  impact  on  the  amount  of 
time  and  effort  associated  with  this  activi¬ 
ty.  This  strategy  is  likely  to  result  in  a 
broader  initial  search  for  qualified  COTS 
components  that  meet  the  desired  func¬ 
tionality  and  security  constraints,  but  then 
a  smaller  set  of  candidate  components 
available  for  detailed  evaluation.  The  cost 
and  effort  impacts  to  this  activity  will  be  a 
function  of  the  security  assurance  level 
required  and  the  number  of  COTS  com¬ 
ponents  available  for  evaluation  that  are 
certified  to  that  level. 

The  strategy  to  buy  and  certify  com¬ 
ponents  is  a  bit  riskier  to  predict  with 
respect  to  effort  or  cost  because  there  is 
an  inherent  risk  that  the  evaluation 
process  may  be  revisited  if  internal  cer¬ 
tification  fails  for  selected  components. 
Integrators  should  take  steps  to  mitigate 
this  risk  by  only  evaluating  components 
from  vendors  with  documented  soft¬ 
ware  development  practices  and  proven 
quality  records.  With  such  risk  mitiga¬ 
tion  strategies  in  place,  this  activity 
would  consist  of  a  broader  initial  search, 
as  all  available  components  are  con¬ 
tenders  followed  by  a  more  detailed  eval¬ 
uation  of  the  few  that  appear  to  meet 
high  quality  standards.  Additionally,  cer¬ 
tification  comes  with  its  own  costs, 
including  fees  for  laboratory  testing, 
modifications  identified  as  the  result  of 
this  testing  (if  modifications  are  possible 
and  desired),  collecting  documentation 


required  for  assurance,  and  fees  to  certi¬ 
fication  agencies. 

The  cost  and  effort  impacts  to  this 
activity  will  be  driven  by  the  security  assur¬ 
ance  level  required,  the  number  of  COTS 
components  likely  to  be  certified  to  that 
level,  the  functional  size  and  complexity  of 
the  COTS  components  that  require  certi¬ 
fication,  and  the  state  and  availability  of 
documentation. 

Negotiate  Terms  With  COTS  Vendors 

If  the  strategy  is  buy  and  wrap,  then  nego¬ 
tiations  with  vendors  should  not  be 
impacted  by  security  constraints.  Vendor 
pre-certification  is  unlikely  to  impact  the 
negotiations  process  either,  unless  the  pre¬ 
certification  is  being  done  as  part  of  the 
negotiated  terms  of  the  contract.  If  the 
certification  is  being  performed  by  the 
integrating  organization,  the  terms  of  the 
contract  should  include  actions  to  be 
taken  if  COTS  components  fail  to  meet 
any  promises  made  with  respect  to  quality 
or  security. 

is  during  the  software 
requirements  analysis 
activity  that  decisions  can 
be  made  as  to  which 
requirements  con  be 
satisfied  with  off-the-shelf 
components.*^ 

Implement  the  COTS-Based  Solution 

The  implementation  activities  for  a 
COTS-based  solution  can  be  affected  by 
security  constraints  in  various  ways.  As 
with  previous  activities,  the  selection  strat¬ 
egy  determines  which  activities  are  affect¬ 
ed  and  to  what  extent. 

•  Tailoring  of  COTS  solution. 
Security-specific  tailoring  tasks  should 
be  handled  as  part  of  the  functional 
requirements  for  the  system.  The 
impact  to  the  cost  of  this  activity 
would  be  a  function  of  the  functional 
size  imposed  through  those  require¬ 
ments. 

•  Modification  of  COTS  software.  If 

the  buy  and  wrap  strategy  is  in  place, 
the  costs  of  modifications  should  not 
change  regardless  of  security  require¬ 
ments  as  the  wrapper  has  isolated  the 
COTS  component  from  the  rest  of 
the  system  in  a  secure  cocoon.  If  the 


COTS  components  are  pre-certified  or 
internally  certified  and  then  modified 
by  the  integrator,  an  entire  recertifica¬ 
tion  must  be  accomplished,  most  like¬ 
ly  at  the  cost  of  the  integrator.  The 
cost  and  effort  for  this  activity  would 
be  driven  by  the  security  assurance 
level  required  and  the  functional  size 
of  the  COTS  component(s)  that  are 
modified.  Institutionalized  software 
development  practices  and  security 
expertise  would  mitigate  some  of  the 
costs  of  this  process. 

•  Design,  code,  and  test  of  glue 
code.  When  a  buy-and-wrap  strategy 
is  employed,  the  glue  code  size  should 
be  expanded  to  include  the  amount  of 
wrapper  code  that  must  be  developed. 
The  cost  of  the  development  of  this 
wrapper  code,  along  with  any  other 
glue  code  that  is  written,  will  be 
impacted  by  the  security  assurance 
level  required.  This  impact  can  be  sub¬ 
stantially  mitigated  when  software 
development  practices  are  institution¬ 
alized  and  when  the  integration  team 
has  training  and  experience  in  develop¬ 
ing  secure  software. 

•  Integration  of  COTS  components 
with  other  COTS  or  custom  com¬ 
ponents.  Integration  and  test  are 
where  the  rubber  meets  the  road.  As 
with  other  non- functional  require¬ 
ments,  security  requirements  are  not 
fully  testable  until  all  the  pieces  of  the 
system  are  working  together.  It  is  pos¬ 
sible  that  certain  combinations  of 
components  create  security  vulnerabil¬ 
ities  where  none  existed  within  the 
individual  components.  Regardless  of 
selection  strategy,  this  activity  will  be 
impacted.  Extent  of  this  impact  is 
determined  by  the  security  assurance 
level  required,  but  is  mitigated  when 
good  software  development  practices 
are  institutionalized  and  the  integra¬ 
tion  team  contains  members  with 
security  training  and  experience. 

Maintain  License,  Subscription,  and 
Royalty  Fees 

If  the  strategy  is  buy  and  wrap,  this  activ¬ 
ity  is  unlikely  to  be  impacted  by  security 
assurance  requirements.  If  COTS  compo¬ 
nents  are  pre-certified  or  internally  certi¬ 
fied,  renewal  time  is  the  time  to  ensure 
that  promises  with  respect  to  security  and 
quality  are  being  maintained  as  the  COTS 
products  are  upgraded  over  time. 

Maintenance  and  Upgrade  of  the 
COTS-Based  Solution 

Maintenance  of  any  COTS-based  system 
can  be  problematic,  particularly  as  the 
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number  of  different  vendors  increases. 
Security  constraints  further  complicate  the 
maintenance  and  upgrade  activities. 

•  Evaluation  and  inclusion  of 
updates  and  upgrades  from  the 
vendor.  When  a  buy-and-wrap  strate¬ 
gy  is  employed,  the  inclusion  of 
upgrades  may  require  modifications  to 
wrapper  code  to  accommodate  new  or 
changed  interfaces.  Upgrades  for  inter¬ 
nally  certified  components  would 
require  recertification.  One  would 
expect  that  precertified  components 
would  recertify  with  each  upgrade  and 
update.  Regardless  of  selection  strate¬ 
gy,  upgrades  and  updates  require  some 
level  of  integration  and  test  at  the  sys¬ 
tem  level  to  ensure  that  security  con¬ 
straints  are  still  met  by  the  system.  The 
cost  of  this  activity  is  driven  by  the 
security  assurance  level,  but  is  mitigat¬ 
ed  by  good  development  practices, 
training,  and  expertise. 

•  Bug  Fixes.  Regardless  of  selection 
strategy,  bug  fixes  will  require  some 
level  of  reintegration  and  test,  which 
requires  reverification  at  the  system  (or 
subsystem)  level  that  these  fixes  have 
not  introduced  security  vulnerabilities. 
Additionally,  if  fixes  are  made  to 
COTS  components  or  to  modifica¬ 
tions  made  to  those  components,  the 
entire  certification  process  for  that 
component  must  be  recertified.  The 
cost  and  effort  of  this  activity  is  driven 
by  the  security  assurance  level,  as  well 
as  the  amount  of  glue  code  and  modi¬ 
fied  code  being  maintained.  This  cost 
can  be  mitigated  with  the  institutional- 
Uation  of  good  software  development 
practices  and  an  integration  team  with 
security  training  and  expertise. 

Conclusions 

More  and  more,  integrators  are  being 
asked  to  deliver  software  systems  that 
meet  high-level  security  constraints  while 
delivering  most  (if  not  all)  of  their  func¬ 
tionality  using  off-the-shelf  components. 
As  integrators  are  just  beginning  to  under¬ 
stand  all  of  the  issues  associated  with  a 
successful  COTS-based  software  project, 
they  now  have  to  understand  how  securi¬ 
ty  assurance  requirements  will  impact 
those  issues  and  what  new  issues  will  be 
introduced. 

Security  constraints  impact  a  project  in 
two  ways.  Functional  security  requirements 
increase  the  functional  size  of  the  software 
system  being  developed  and  need  to  be 
treated  in  the  same  way  as  all  other  func¬ 
tional  requirements  being  met  by  COTS 
components  or  homegrown  code.  Non¬ 
functional  security  requirements  to  attain  a 


specific  level  of  security  assurance  require 
additional  processes,  documentation,  test¬ 
ing,  and  verifications.  The  additional  focus 
on  these  activities  will  result  in  additional 
cost  to  COTS  integrators.  Most  security 
vulnerability  in  software  is  a  result  of  poor 
quality  and  poor  or  inconsistent  software 
development  practices.  By  improving 
these  practices  and  employing  people  with 
expertise  in  security  and  excellent  soft¬ 
ware  development  skills,  integrators  can 
reduce  the  cost  increases  driven  by 
requirements  for  security. 

This  article  reviewed  the  impacts  of 
security  constraints  on  the  cost  of  a  proj¬ 
ect  to  deliver  COTS-based  software  sys¬ 
tems.  It  reviewed  these  impacts  in  the 
context  of  the  activities  required  to  suc¬ 
cessfully  implement  a  COTS-based  sys¬ 
tem  and  highlighted  those  areas  where 
security  constraints  apply.  The  security- 
related  factors  found  most  likely  to  impact 
costs  were  the  COTS  selection  strategy 
employed  and  the  security  assurance  level 
required.  In  organizations  where  invest¬ 
ments  have  already  been  made  to  institu¬ 
tionalize  good  software  development 
processes  and  hire  people  with  the  train¬ 
ing  and  experience  to  deliver  secure, 
defect-free  software,  the  cost  impact  of 
security  requirements  is  less  severe.^ 

References 

1.  Minkiewicz,  A.  ‘'The  Six  Steps  to  a 
Successful  COTS  Implementation.” 
Crosstalk  Aug.  2005  <www.stsc. 
hill.af.mil/ crosstalk/ 2005/08/0508 
Minkiewicz. html> . 

2.  The  White  House.  “National  Strategy 
to  Secure  Cyberspace.”  Feb.  2003 
<www.whitehouse.gov/ pcipb>. 

3.  Software  Process  Subgroup  of  the 
Task  Force  on  Security  Across  the 
Software  Development  Life  Cycle. 
“Process  to  Produce  Secure  Software.” 
National  Cyber  Security  Summit,  Mar. 
2004. 

4.  The  National  Institute  of  Standards 
and  Technology  and  the  National 
Security  Agency.  “Common  Criteria 
for  Information  Technology  Security 
Evaluation,  Vers.  2.1.”  National  Insti¬ 
tute  of  Standards  and  Technology. 
Aug.  1999  <http://csrc.nist.gov/cc>. 

5.  Minkiewicz,  A.  “The  Real  Costs  of 
Developing  a  COTS-Based  System.” 
Proc.  for  IEEE  Conference  on 
Aerospace  and  Defense,  Big  Sky 
Montana,  Mar.  2004. 

6.  Center  for  Software  Engineering. 
“CoCOTS  White  Paper.”  Los  Angeles, 
CA:  University  of  Southern  California, 
June  1997  <http://sunset.usc.edu/ 
research/ COCOTS/ cocots_main. 


html>. 

7.  Reifer,  D,  et  al.  “Estimating  the  Cost 
of  Security  for  COTS  Software.”  2nd 
International  Conference  on  COTS- 
Based  Software  Systems.  Los  Angeles, 
CA.  Mar.  2003. 

8.  Festa,  P.  “Study  Says  Buffer  Overflow 
Is  Most  Common  Security  Bug.”  C- 
Net  news.com  23  Nov.  1999  <http:/ / 
news.com.com>. 


About  the  Author 


Arlene  F.  Minkiewicz 

is  chief  scientist  of  the 
Cost  Research  Depart¬ 
ment  at  PRICE  Systems. 
She  is  responsible  for  the 
research  and  analysis 
necessary  to  keep  the  suite  of  PRICE 
estimating  products  responsive  to  cur¬ 
rent  cost  trends.  In  her  20-year  tenure 
with  PRICE,  Minkiewicz  has  researched 
and  developed  the  software  cost  estimat¬ 
ing  relationships  that  were  the  corner¬ 
stone  for  price’s  commercial  software 
cost  estimating  model,  ForeSight,  and 
invented  the  Cost  Estimating  Wizards 
originally  used  in  ForeSight  that  walk  the 
user  through  a  series  of  high-level  ques¬ 
tions  to  produce  a  quick  cost  analysis.  As 
part  of  this  effort,  she  invented  a  sizing 
measurement  paradigm  for  object-ori¬ 
ented  analysis  and  design  that  allows 
estimators  a  more  efficient  and  effective 
way  to  estimate  software  size.  She 
recently  received  awards  from  the 
International  Society  of  Parametric 
Analysts  and  the  Society  of  Cost 
Estimating  and  Analysis.  Minkiewicz 
contributed  to  a  new  parametric  cost 
estimating  book  with  the  Consortium 
for  Advanced  Manufacturing  Inter¬ 
national  called  “The  Closed  Loop: 
Implementing  Activity-Based  Planning 
and  Budgeting,”  and  she  frequently  pub¬ 
lishes  articles  on  software  estimation  and 
measurement.  She  has  been  a  contribut¬ 
ing  author  for  several  books  on  software 
measurement  and  speaks  frequently  on 
this  topic  at  numerous  conferences. 


PRICE  Systems 

1 7000  Commerce  PKWY  STE  A 
Mt.  Laurel,  NJ  08054 
Phone:  (856)  608-7222 
Fax:  (856)  608-7247 
E-mail:  arlene.mmkiewicz@ 
pricesystems.com 


November  2005 


www.stsc.hill.af.mil  27 


Software  Component  Interoperability 


Jeffrey  Voas 
SAIC 


When  a  software  system  fails,  a  confusing  and  complex  liability  problem  ensues  for  all  parties  that  have  contributed  soft¬ 
ware  functionality  (whether  commercial  off-the-shelf  [COTS]  or  custom)  to  the  system.  This  article  explores  the  interop¬ 
erability  problems  created  by  defective  COTS  software  components,  and,  in  particular,  the  hidden  interfaces  and  non-func- 
tional  behaviors.  It  also  looks  into  the  problem  of  composing  non-functional  behaviors  that  are  related  to  quality-of-serv- 
ice  attributes. 


When  there  are  complaints  about  the 
quality  of  the  software,  they  are 
usually  directed  at  the  software’s  behav¬ 
ior,  and  not  the  underlying  text  [1]. 
Therefore  it  is  important  to  define  what 
constitutes  bad  behavior  in  software. 

Bad  software  behavior  is  a  function 
of  the  environment  that  the  software 
resides  in,  and  the  environment  is  a  mix¬ 
ture  of  the  underlying  hardware,  the 
operating  system,  potential  threats,  the 
operational  profile,  other  external  soft¬ 
ware  components  that  interact  with  the 
software,  and  the  manner  in  which  the 
software  will  be  used  [2].  Since  these  fac¬ 
tors  affect  the  software  system’s  behav¬ 
ior,  the  architectural  plan  for  how  com¬ 
ponents  are  to  be  integrated  should  be, 
in  part,  based  on  these  factors. 

For  example,  a  toaster  comes  with  a 
warranty  and  that  warranty  assumes  a 
particular  environment,  such  as  sitting 
on  a  kitchen  countertop.  Now  take  a 
working  toaster,  put  it  in  another  envi¬ 
ronment,  like  a  bathtub  full  of  water, 
and  the  behavior  of  the  toaster  is  not 
going  to  be  the  same,  and  the  warranty 
no  longer  applies.  The  same  argument 
applies  to  software. 

Will  the  Real  Operational 
Profile  Please  Stand  Up? 

One  of  the  most  important  issues  dur¬ 
ing  requirements  generation  is  defining, 
as  best  as  possible,  the  software  environ¬ 
ment;  its  operational  profile  is  key. 

Each  piece  of  software  has  a  set  of 
input  vectors  that  may  be  executed  dur¬ 
ing  testing  or  field  usage.  That  is  the  soft¬ 
ware’s  input  domain.  The  operational profile  is 
simply  a  probability  distribution  function 
(PDF)  for  the  input  vectors  of  the  input 
domain.  This  means  each  input  vector 
has  a  certain  probability  of  being  chosen 
during  testing  or  field  usage,  and  the 
PDF  is  what  defines  the  probabilities  for 
each  input  vector.  For  example,  if  the 
input  domain  has  10  input  vectors,  and 
each  input  vector  is  as  equally  likely  to  be 
selected  as  any  other  vector,  then  each 


vector  has  a  10  percent  chance  of  being 
selected.  (Note  that  the  operational  pro¬ 
file  is  highly  important  when  system-level 
reliability  testing  occurs  [3].) 

Thus,  without  an  accurate  description 
of  the  operational  profile,  predictions 
concerning  how  the  software  will  behave 
in  the  field  are  unlikely  to  be  accurate 
since  each  individual  input  vector  can 
cause  differing  behaviors.  Therefore, 
spending  the  extra  time  to  contemplate 
the  eventual  operational  profile  and  tar¬ 
get  environment  is  often  as  important  as 
defining  the  software’s  functionality  dur¬ 
ing  requirements  definition. 

Tolerating  Component  and 
Subsystem  Failures 

More  and  more  software  is  delivered  to 
system  integrators  in  black-box  form; 
these  components  are  packaged  as  exe¬ 
cutable  objects  (with  licensing  agree¬ 
ments  that  forbid  decompilation  back  to 
source  code),  e.g.,  dynamic  link  libraries 
that  originate  from  third-party  sources, 
e.g.,  commercial  off-the-shelf  (COTS) 
software.  A  worthy  goal,  then,  is  to  pro¬ 
vide  a  methodology  for  determining 
how  well  a  system  can  perform  when 
particular  black  boxes  are  of  such  poor 
quality  that  interoperability  and  integra¬ 
tion  problems  are  almost  inevitable. 

One  technique  for  assessing  the  level 
of  interoperability  between  COTS  soft¬ 
ware  components  and  custom  compo¬ 
nents  is  called  Interface  Propagation 
Analysis  (IPA)  [4].  IPA  perturbs  (i.e., 
corrupts)  the  states  that  propagate 
through  the  interfaces  that  connect 
COTS  software  components  to  other 
components.  IPA  is  one  form  of  software 
fault  injection  [5].  By  corrupting  data 
going  from  one  component  to  a  succes¬ 
sor  component,  failure  of  the  predeces¬ 
sor  is  simulated,  and  its  impact  on  the 
successor  can  be  assessed.  This 
approach  allows  for  measuring  the  level 
of  intolerance  when  one  component 
fails,  sending  junk  information  (or  even 
a  lack  of  information)  to  its  neighbor. 


To  modify  the  information  (states) 
that  components  use  for  inter-compo¬ 
nent  communication,  write  access  to 
those  states  is  required  (to  modify  the 
data  in  those  states  during  the  simula¬ 
tion).  This  is  done  by  creating  a  small 
software  routine  called  PERTURB  that 
replaces  the  original  output  state  with  a 
different  (corrupted)  state.  This  is,  of 
course,  done  as  the  system  executes.  By 
simulating  the  failure  of  various  soft¬ 
ware  components,  we  can  assess 
whether  the  remainder  of  the  system 
can  tolerate  it. 

I  will  illustrate  this  by  using 
Advanced  IBM  Unix’s  (AIX)  cosQ  func¬ 
tion  in  this  example.  Note  that  AIX’s 
cosQ  is  a  fine-grained  COTS  utility  for 
which  we  do  not  have  access  to  the 
source  code: 

double  cos(double  x) 

This  declaration  indicates  that  the  cos() 
function  receives  a  double  integer  (con¬ 
tained  in  variable  x)  and  returns  a  double 
integer.  Because  of  C’s  language  con¬ 
straints,  the  only  output  from  cos()  is 
the  returned  value,  and  hence  that  is  all 
that  IPA  fault  injector  can  corrupt. 

To  see  how  this  analysis  works,  con¬ 
sider  an  application  that  contains  the 
following  code: 

if  (cos(a)  >  THRESHOLD) 

{ 

do  something 

} 

The  goal,  then,  is  to  determine  how  the 
apphcation  will  behave  if  cos()  returns 
incorrect  information.  To  do  so,  the 
return  value  from  the  call  is  modified; 

if  (PERTURB(cos(a))  >  THRESHOLD) 

{ 

do  something 

} 

Note  that  IPA  is  more  than  just  an 


28  CrossTalk  The  Journal  of  Defense  Software  Engineering 


November  2005 


Software  Component  Interoperability 


interesting  research  idea.  It  has  been  used 
successfully  in  a  variety  of  critical  soft¬ 
ware  systems  that  required  better  tech¬ 
niques  to  perform  impact  analysis  and 
assess  potential  interoperability  conflicts; 
those  case  studies  are  compiled  in  [5]. 

Composing  ilities 

Clearly,  today’s  COTS  components  are 
much  more  substantial  in  functionality 
and  complexity  than  the  previous  AIX 
example.  One  of  the  real  problems  in 
composing  today’s  COTS  components 
that  have  advanced  functionality  and 
complexity  is  combining  large  compo¬ 
nents  that  each  have  varying  quality-of- 
service  (QoS)  attributes  into  one  com¬ 
ponent  that  now  inherits  a  new  set  of 
QoS  attributes. 

Much  of  the  work  from  the  past  10 
years  into  component-based  software 
engineering  (CBSE)  and  component- 
based  development  (CBD)  has  dealt 
with  functional  composability  (FC).  FC 
is  concerned  with  whether  the  following 
is  true: 

F(A)_F(B)  =  F(A_B) 

where, 

_  is  some  mathematical  operator 

That  is  to  determine  whether  a  com¬ 
posite  system,  F(A  _  B),  is  created  that 
has  the  desired  functionality  after  join¬ 
ing  A  and  B.  Therefore,  A  and  B  now 
have  a  way  to  communicate,  whether 
one-directional  or  bidirectional.  Instead 
of  acting  alone,  they  now  act  together  as 
one  unit. 

But,  increasingly,  the  software  com¬ 
munity  is  discovering  that  FC,  even  if  it 
were  a  solved  problem,  is  not  mature 
enough  for  other  serious  concerns  that 
arise  in  CBSE  and  CBD  such  as  the  prob¬ 
lem  of  composing  ilities.  Ilities  are  non¬ 
functional,  QoS  properties  of  software 
components  and  they  define  characteris¬ 
tics  such  as  security,  reliability,  fault-toler¬ 
ance,  performance,  availability,  safety, 
testability,  survivability,  maintainability, 
etc.  The  properties,  as  weU  as  others,  are 
what  ultimately  determine  whether  the 
software  is  well-behaved  or  not. 

The  problem  stems  from  our  inability 
to  know  a  priori^  for  example,  what  the 
security  of  a  system  composed  of  two 
components  —  A  and  B  —  will  be  even  if 
we  have  knowledge  about  the  security 
capabilities  built  into  A  and  knowledge 
about  the  security  capabilities  of  B.  Why? 
Because  the  security  of  the  composite 
system  is  based  on  more  than  just  the 


security  of  the  individual  components. 

For  example,  suppose  that  A  is  an 
operating  system  and  B  is  an  intrusion 
detection  system.  Operating  systems 
usually  have  some  level  of  authentica¬ 
tion  security  built  into  them,  and  intru¬ 
sion  detection  systems  have  definitions 
for  the  types  of  event  patterns  that  like¬ 
ly  warn  of  an  attack.  Thus  the  security 
of  the  composition  of  these  two  com¬ 
ponents  depends  on  the  security  models 
built  into  the  individual  components. 

But  even  if  A  has  a  worthless  security 
policy  or  flawed  implementation,  the 
composite  can  still  be  secure.  How?  By 
simply  making  the  performance  of  A  so 
poor  that  no  one  can  gain  access,  i.e.,  if 
the  intrusion  detection  system  is  so  ineffi¬ 
cient  at  performing  an  authentication, 
then  in  a  strange  way,  security  is  actually 
offered.  And  if  the  implementation  of 
As  security  mechanism  is  so  unreliable 
that  it  disallows  access  to  all  users,  even 
legitimate  ones,  then  strangely  security  is 
again  increased.  While  these  last  two 
examples  are  not  a  reasonable  way  to 
achieve  higher  levels  of  system  security, 
both  do  actually  decrease  the  likelihood 
that  a  system  will  be  successfully  attacked. 

Using  the  same  example  of  A  and  B, 
this  time  assume  that  A  provides  excel¬ 
lent  security  and  B  provides  excellent 
security.  The  usefulness  of  B’s  security 
mechanisms  is  a  function  of  calendar 
time  because  new  threats  and  ways  to 
intrude  are  always  being  discovered.  So 
even  if  you  could  create  a  scheme  that 
determines  the  following: 

Security(A)  _  Security(B)  =  Security 
(A_B) 

the  security  offered  by  B  is  always  a 
function  of  which  version  of  B  is  being 
composed  with  A,  what  recent  new 
threats  have  arisen,  and  how  many  of 
these  new  attack  patterns  have  been 
built  into  B. 

So  the  question  then  comes  down  to 
which  ilities,  if  any,  are  easy  to  compose? 
The  answer  is  that  there  are  no  ilities 
that  are  easy  to  compose,  and  some  are 
much  harder  than  others.  Further,  there 
are  no  widely  accepted  algorithms  for 
how  to  do  so. 

For  this  problem  applied  to  reliability, 
consider  a  2-component  system  in  which 
component  A  feeds  information  in  B, 
and  B  produces  the  output  of  the  com¬ 
posite  (two  components  in  series). 
Assume  that  both  components  are  reli¬ 
able.  What  can  we  assume  about  the 
composite’s  reliability?  While  this  infor¬ 
mation  certainly  suggests  that  the  com¬ 


posite  system  will  be  reliable,  it  must  be 
recognized  that  components  (which  were 
tested  in  isolation  for  their  individual  reli¬ 
abilities)  can  suddenly  behave  unreliably 
when  connected  to  each  other,  particular¬ 
ly  if  the  isolated  test  distributions  did  not 
at  all  reflect  the  type  of  information  that 
A  will  be  sending  to  B. 

This  brings  us  back  to  the  impor¬ 
tance  of  understanding  the  environment 
and  operational  profile  for  each  compo¬ 
nent.  Further,  there  can  be  non-func¬ 
tional  behaviors  that  cannot  be  observed 
nor  manifest  themselves  until  after  com¬ 
position  occurs.  Such  behaviors  can 
undermine  the  reliability  of  the  compo¬ 
sition.  Finally,  if  one  of  the  components 
is  simply  the  wrong  component  — 
although  highly  reliable  —  then  naturally 
the  resulting  system  will  be  useless. 

In  addition  to  reliability  and  security, 
one  ility  that,  at  least  on  the  surface, 
appears  to  have  the  best  possibility  of 
successful  composability  is  perform¬ 
ance.  But  even  that  is  problematic  from 
a  practical  sense.  The  reason  stems  from 
the  fact  that  even  if  a  performance 
analysis  was  performed  on  a  single  com¬ 
ponent,  the  practical  consequences  on 
that  component’s  performance  after  a 
composition  with  another  component 
may  depend  heavily  on  the  hardware  and 
other  physical  resources.  That  could 
require  that  different  hardware  variables 
might  need  to  be  dragged  along  with  a 
certificate  that  states  only  minimal, 
worst-case  claims  about  the  perform¬ 
ance  of  the  component. 

For  example,  in  the  pharmaceutical 
industry,  drugs  come  with  endless  warn¬ 
ings/rules  as  to  who  should  take  them  and 
who  should  not.  In  the  discussion  here, 
the  hardware  variables  are  the  various 
other  medical  circumstances  of  an  indi¬ 
vidual  slated  for  a  particular  drug  (liver 
problems,  heart  problems,  etc.).  Clearly, 
this  complex  issue  creates  serious  prag¬ 
matic  difficulties  and  again  takes  us  back 
to  the  need  for  a  precise  definition  of 
what  is  the  real  environment  of  a  software 
component  [2,  6].  Today,  the  definition  of 
what  is  the  real  environment  of  a  compo¬ 
nent  is  an  open  question,  needing  new 
thinking  and  new  research  efforts  [7] . 

Note  that  non- functional  behaviors 
are  particularly  worrisome  in  COTS 
software  products.  Non-functional 
behaviors  can  include  malicious  code 
(Trojan  horses,  logic  bombs,  etc.)  and 
any  other  behavior  or  side  effect  that  is 
not  documented. 

Another  worrisome  problem  facing 
CBSE  and  CBD  is  hidden  interfaces. 
Hidden  interfaces  typically  are  channels 
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through  which  application  or  compo¬ 
nent  software  is  able  to  convince  the 
operating  system  to  execute  undesirable 
tasks  or  processes. 

Interestingly,  IPA  can  partially 
address  the  issue  of  detecting  hidden 
interfaces  and  non- functional  behaviors 
by  forcing  software  systems  to  reveal 
those  behaviors  after  the  input  stream  of 
a  COTS  component  receives  corrupted 
input.  Injecting  corrupt  information 
into  a  component  can  possibly  force  it 
to  execute  different  (and  rarely  execut¬ 
ed)  code  paths,  flushing  out  behaviors 
that  would  not  normally  occur  with 
uncorrupted  information. 

The  reason  that  IPA  can  only  be  par¬ 
tially  successful  in  doing  so  is  that  IPA  is 
a  function  of  (1)  the  number  of  cor¬ 
rupted  inputs  used,  and  (2)  the  number 
of  executions  of  the  software.  Just  as 
exhaustive  testing  is  the  only  way  to  guar¬ 
antee  correctness  via  testing,  IPA  is  lim¬ 
ited  in  the  amount  of  analysis  it  can  per¬ 
form  to  detect  hidden  interfaces  and 
non- functional  behaviors.  In  short,  you 
cannot  test  every  potential  combination 
of  ways  that  you  can  inject  corrupted 
data  to  see  what  results,  and  where  those 


results  propagate. ♦ 
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Design?  We  Don’t  Need  No  Stinkin’  Design! 
(or  “How  to  Fail  Without  Really  Trying”) 


Let  me  start  by  pointing  out  that  I  am  a  compulsive  list- 
maker  and  planner.  As  a  military  brat,  I  grew  up  over¬ 
seas.  Recently,  I  decided  to  take  a  vacation  to  Istanbul, 
Turkey  where  my  father  had  been  stationed  from  1964  to 
1966.  To  me,  a  large  part  of  the  fun  of  a  vacation  is  the 
preparation  and  planning.  Making  lists  —  what  to  carry,  what 
sites  to  visit  ranked  by  importance  (with  categories  of 
Essential,  Important,  or  Optional)  —  is  exhilarating.  To  me, 
half  of  the  fun  is  examining  all  the  tourist  guides,  and 
savoring  the  experience  of  the  trip  by  preparing  for  it. 

When  I  showed  my  co¬ 
workers  my  list  of  sites  I  want¬ 
ed  to  visit,  sorted  both  by  dis¬ 
trict  and  importance,  the  word 
geek  kept  creeping  up  in  their 
responses. 

On  the  other  hand,  these 
obsessive-compulsive  traits 
seem  to  be  a  good  thing  when 
talking  about  design. 

When  you  mention  design  to 
most  developers,  they  start 
thinking  of  program  design. 

Now  program  design  is  indeed 
one  part  of  design,  and  a  very 
important  part.  Program  (or 
module)  design  is  where  you 
convert  the  algorithms  and 
logic  of  the  design  into  exe¬ 
cutable  code,  assuming  that  the 
algorithm  and  logic  were  avail¬ 
able  —  assuming  that  the  developer  doesn’t  know  more  than 
the  designer  —  and  improve  the  logic. 

Module  design  is  the  easy  part  of  design,  however. 
Design,  depending  upon  the  source  and  reference  cited, 
consists  of  at  least  four  phases:  architecture  design,  interface 
design,  data  design,  and  module  design.  This  ordering  also 
captures  the  correct  order  of  importance  and  difficulty. 

Architectural  design  is  where  a  grand  designer  sets  forth 
the  vision  of  the  system.  It  includes  what  the  major  sub¬ 
sections  are,  the  major  functionality,  and  general  feeling  of 
how  the  overall  system  is  going  to  work.  Even  with  auto¬ 
mated  tools,  this  step  is  hard.  It  is  typically  said  that  the 
architectural  design  should  have  a  feel  to  it  that  says,  “Well, 
of  course  this  is  the  way  that  the  system  is  supposed  to  look.” 
It  should  appear  simple.  Unfortunately,  as  system  designers 
know,  simplicity  is  very  difficult  to  achieve.  Without  a  good 
architecture,  however,  the  system  never  seems  to  work  well 
—  tasks  have  to  be  shared  across  major  subsystems,  increas¬ 
ing  complexity,  and  decreasing  cohesion. 

As  part  of  the  architectural  design,  interfaces  have  to  be 
established  and  enforced.  In  a  perfect  world,  this  step 
should  be  relatively  simple.  Unless,  of  course,  you  are  deal¬ 
ing  with  legacy  systems  that  already  have  existing  interfaces; 
interfaces  that  were,  at  best,  designed  using  30-year-old 


functional  decomposition,  and  do  not  fit  well  with  object- 
oriented  languages  of  the  present. 

When  I  teach  design,  I  tell  my  students  that  75  percent 
of  all  errors  will  eventually  be  traced  to  poor  interfaces. 
Most  don’t  believe  me  at  first,  but  eventually  find  out  that  I 
was  right.  The  problem  with  interface  incompatibilities  is 
that  they  often  don’t  show  up  during  unit  testing,  and  can¬ 
not  be  discovered  until  integration  testing.  Of  course,  the 
later  in  the  life  cycle  that  errors  are  discovered,  the  more 
expensive  they  are  to  fix. 

Do  the  words  “Boyce- 
Codd  Normal  Form”  mean 
anything  to  you?  How  about 
“First,  Second,  or  Third 
Normal  Form”?  If  so,  you’re 
in  the  minority.  These  terms 
refer  to  relationships  be¬ 
tween  data  and  keys.  Twenty 
years  ago,  you  wouldn’t  have 
dreamt  of  designing  a  data¬ 
base  without  having  an 
expert  determine  an  opti¬ 
mum  arrangement  of  keys 
and  relationships.  Now, 
unfortunately,  cheap  disk 
storage  and  fast  processors 
allow  data  to  be  thrown  togeth¬ 
er.  However,  as  applications 
evolve,  grow,  and  are  modi¬ 
fied  due  to  changing  and  new 
requirements,  bad  data 
design  can  slow  down  your  application.  It  can  also  con¬ 
tribute  to  problems  with  duplication  of  data,  along  with 
consistency  and  correctness  of  the  data. 

In  short:  design  is  hard,  very  hard.  The  larger  and  more 
complex  the  application,  the  more  important  design 
becomes.  If  you  have  a  small  application  that’s  going  to 
exist  on  the  Web  for  a  few  months  at  the  most,  design  is  no 
problem.  On  the  other  hand,  if  you  have  a  $10  million  proj¬ 
ect,  projected  to  interface  with  existing  Department  of 
Defense  systems  with  an  expected  life  of  20  years,  design  is 
critical. 

Of  course,  you  can  probably  get  a  working  system  with¬ 
out  much  design.  Enough  to  get  user  sign-off.  Of  course, 
the  first  time  you  try  and  make  any  modifications  or  addi¬ 
tions  to  the  system,  the  lack  of  a  design  will  cause  it  to  fall 
apart  like  a  house  of  cards. 

Not  to  worry.  There’s  always  time  and  money  to  do  it 
over  with  a  good  design,  right? 

—  David  A.  Cook,  Ph.D. 

Senior  Research  Scientist 
The  AEgis  Technologies  Group,  Inc. 

dcook@aegistg.com 
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